Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Android—Why Dalvik?

Reply
Thread Tools

Android—Why Dalvik?

 
 
BGB
Guest
Posts: n/a
 
      06-08-2011
On 6/8/2011 9:16 AM, Abu Yahya wrote:
> On 6/6/2011 2:15 PM, BGB wrote:
>> I was curious earlier, and downloaded the Android SDK, and made an
>> inconvenient observation:
>> the emulator is slow...
>>
>> emulating an older version of Android, it is ok, but trying to emulate a
>> newer version, performance is unusably slow.
>>
>>
>> maybe a similar issue might apply to iOS, meaning that maybe the
>> emulated version is not an adequate representation of how it will behave
>> on real HW...
>>

>
> I must mention that it's not the case with the iOS simulator. I've been
> using it for sometime now, and it always starts in a snap and responds
> amazingly well. It's the envy of my colleagues who code for the Android
> and Blackberry platforms using Eclipse, where the emulators take forever
> to load.
>


maybe Apple knows more what they are doing?...


I tried simulating Android 3.1, but the emulated OS was generally very
unreponsive, like basically "click, hold, wait several seconds,
something happens, ..." eventually got a lock image on the screen, and
it would no longer do anything past this point...


Android 2.x is a bit more responsive though, but still not really an
example of raw speed either (turning off some graphical effects though,
like menu-transition and scrolling effects, did make it a bit faster
though).

I also observed that they have a shell, but the shell sort of sucks (not
nearly as good as Bash...).

I am wondering it this is more a matter with fundamental limitations
(say, Android takes too much processing power or requires simulating a
GPU or similar), QEMU (not simulating ARM efficiently, ...), or with
Google (say, they wrote inefficient HW emulation code, ...).


in total, I am not terribly impressed either with the emulator or with
the NDK tools (strange build setup, ...).

since I don't have a smartphone either, there is not a whole lot of real
reason for me to bother with all this.


or such...
 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      06-08-2011
On 11-06-08 11:10 AM, Michael Wojcik wrote:
> Lawrence D'Oliveiro wrote:
>> In message <isck8i$92j$(E-Mail Removed)>, Joshua Cranmer wrote:
>>> I'm sure that outside of GNU or FSF-blessed programs, there are a lot of
>>> C/C++ programs that wouldn't compile on Unix-ish-but-not-Linux
>>> platforms, like OpenBSD or Solaris.

>>
>> How about this one <http://www.blender.org/>, with a million lines of C
>> code, last I counted. Or this one <http://dev.mysql.com/>. Or this one
>> <http://www.libreoffice.org/>. Or this one <http://httpd.apache.org/>.

>
> So your claim is that the total number of C and C++ programs, minus
> four, is less than "a lot"?
>
> Though to be honest, I don't really see what the point is. I think
> Joshua is overestimating the number of C and C++ programs that are
> specific to Linux and won't build on OpenBSD or Solaris. There are
> definitely some, but IME they're usually the ones that deliberately
> use features peculiar to Linux, for whatever reason.
>
> (A better argument might have been the number of C and C++ programs
> that run on x86 Linux but either don't build or fail on one of the
> pickier UNIXes, such as HP-UX for Itanium. But even then it's a quibble.)
>
>
> What's more important is the generally poor quality of C code. (I
> think much C++ is also poorly written, but arguing that is more
> complicated, because it's a far larger language with more latitude for
> programmer choice.)
>
> So let's look at your examples.
>
> Blender: Has about 260 open bugs, including memory allocation issues
> and assertion failures. Much of the source is C++, which I'm not going
> to look at now; but the C source is problematic. For example, there
> are a few uses of strncpy. strncpy has broken semantics; it is never
> the right choice. Blender also includes its own implementation of
> strncpy (BLI_strncpy), for no readily apparent reason, and most of the
> code uses that; but it's sub-optimal. It also uses strcpy extensively,
> and I'm not convinced all of those are safe, for example in the
> makesrna implementation. That's just from a minute of glancing at the
> source.
>
> MySQL: 145 bugs filed in the past 30 days, some of which are clearly
> coding errors (eg #61303, #6120. I don't want to take the time right
> now to prowl through the sources, but the project does not have a
> great track record; see CVE-2009-2446, CVE-2006-1516 through
> CVE-2006-1518, CVE-2010-3676 through CVE-2010-3683, and so on.
>
> LibreOffice: A fork of the OOo code, which does not have a great track
> record. Consider CVE-2010-3450 through -3454, etc. And while those
> CVEs don't list LibreOffice among vulnerable products, the SuSE
> LibreOffice update claims it's vulnerable (see [1]). I suspect the
> relative lack of official vulnerability reports for LibreOffice is
> because they're generally reported against OOo instead. And since LO
> has significant additional features on top of the OOo base, it has a
> lot more room for additional mistakes.
>
> Apache: An outlier project, with excellent funding and a great many
> eyes on the code. That hasn't kept it free of errors. Take a look at
> the brand-new CVE-2011-1921, for example. Or CVE-2011-1928, a classic
> error in C code, caused by a fix to the earlier CVE-2011-0419. '0419
> and '1928 are only DoS vulnerabilities; but that's bad enough.
>
>
> And these are extremely popular projects, so they get a lot of
> attention. Less-used and less-examined code tends to be much worse.
>
>
> [1] http://secunia.com/advisories/43837/
>

I'll throw a few more into the mix. These are two pieces of C/C++
software that I had reason to use at work a few months. One well-known,
one not so much so.

Case A: I needed to write a web services client in C. So I went with
Axis 2 C. My initial build attempt was on Mac OS X 10.6, which is a
certified UNIX 03. It didn't. Come to find out that some fellows have
worked out the handful of (relatively simple) patches needed to fix the
#ifdef's for Mac OS X. Seeing as how Axis 2 C purports to be implemented
with portability this wasn't a good start.

I got the sucker built on Mac OS X. After generating the stubs for a
working WSDL (you need to use a Java-based tool to do this), I
discovered real soon that an important struct that is used frequently in
generated stub code (by used I mean often used by value; e.g.
de-referenced pointers) had its full declaration buried in a .c
implementation file for the _library_; not in the corresponding header.

It has been quite a while since I wrote any C prior to this, but I
figured this wasn't quite right. Especially since there was no way the
client code would compile with just the headers for the Axis 2 C
library. So maybe I'm missing something really obvious here, but there's
no denying the fact that in two different ways what should have compiled
out of the box did not. The error was a standard "storage size not
known" kind of thing. It was easy enough to fix (with some refactoring
of the Axis 2 C library, and re-building it), which makes the situation
worse somehow.

I eventually dispensed with Axis 2 C altogether - this experience didn't
make me happy, and a different design decision let me move to
higher-level .NET APIs. NOt to mention, the Axis 2 C API docs sucked, so
I ended up generating some useful ones using Doxygen - another black
mark - *and* the API itself could have been better.

I might note that I ran across one comment by an Axis 2 C developer
where he said that the model to be followed was

"typedef done inside the header and the struct declaration is in
source...in a case you still want to move the struct to the header (it
is not a much recommended approach in c programming) ... [Ed. How-To
description of procedure follows]"

Maybe I missed something in my years away from C, but those
recommendations were new to me.

Case B: I was working with the source code for a Windows printer driver
that I wished to modify. I tried to build it with VC++, several
versions, and just could not easily do it - the code was studded with
UNIX API calls. As soon as I hacked one problem it led to others.

To this day I can't understand why a group of developers - moreover, a
group of developers who were "good" enough to write a working and fairly
sophisticated Windows printer driver - insisted on thoroughly mixing
Windows code with UNIXish code. It's jarring to see the use of UNIX I/O
in the same source along with MS-inspired Hungarian notation and MFC
macros. It's hard to read...plus I hate a lot of those macros.

I eventually only succeeded in building this driver from source by using
a very specific version of the Dev-C++ IDE, namely the one with an exact
version of mingw included. Even a later version of standalone mingw on
the command line, using the *supplied Makefile*, would not build this
driver. It had to be the mingw included with Dev-C++...using that makefile.

Again, maybe it's just me, but this smacks of laziness and user
unfriendliness. I respect the efforts put in by the mingw and cygwin
people, but the point of those is to make it easier to use existing UNIX
stuff on Windows. If you have the opportunity to write a C/C++ Windows
printer driver *from scratch* you write it the Microsoft way, IMHO.

This team did one other thing which I really, really disliked. Their
printer driver - it created image files actually - uses libpng, libjpeg,
libtiff and zlib. Each and every one of these builds OK on Windows,
producing a DLL and LIB along with headers that can be used by other
projects in the usual way...I know, because I've built them on Windows
enough times over the years. What these guys did was pull in all of the
source for these libraries, and bundled them in with their own code. So
the printer driver build was intimately intermingled with compiling and
linking the code for those 4 libraries.

I'm sorry, but that's just not the way it's supposed to work.

In this case too the experience leaves me with the impression that it's
working but substandard C/C++ code. Cutting corners to suit your own
development preferences means you might be cutting corners somewhere else.

AHS
 
Reply With Quote
 
 
 
 
Joshua Cranmer
Guest
Posts: n/a
 
      06-09-2011
On 6/8/2011 4:38 PM, Arved Sandstrom wrote:
> What these guys did was pull in all of the
> source for these libraries, and bundled them in with their own code. So
> the printer driver build was intimately intermingled with compiling and
> linking the code for those 4 libraries.
>
> I'm sorry, but that's just not the way it's supposed to work.


I don't know Windows development as well as I do Linux, but in Linux at
least, it is "very hard" to link userspace libraries into kernel
modules, so I suspect that Windows drivers have the same issue: you need
to have those libraries statically linked in.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      06-09-2011
On 11-06-08 09:28 PM, Joshua Cranmer wrote:
> On 6/8/2011 4:38 PM, Arved Sandstrom wrote:
>> What these guys did was pull in all of the
>> source for these libraries, and bundled them in with their own code. So
>> the printer driver build was intimately intermingled with compiling and
>> linking the code for those 4 libraries.
>>
>> I'm sorry, but that's just not the way it's supposed to work.

>
> I don't know Windows development as well as I do Linux, but in Linux at
> least, it is "very hard" to link userspace libraries into kernel
> modules, so I suspect that Windows drivers have the same issue: you need
> to have those libraries statically linked in.
>

I appreciate the point you make. In this case the thing is based on the
MS universal printer driver (Unidrv), and the UI and rendering plugins
for that, plus the port monitor that the project also supplies, are all
user-mode DLLs. Furthermore, the function of _this_ port monitor is
ultimately to write image files, not to communicate with kernel-mode
port drivers even.

AHS
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      06-09-2011
Michael Wojcik <(E-Mail Removed)> writes:
>VB.NET is in many ways closer to C# than it is to historical BASIC.
>It's trivial to compile VB.NET into MSIL and then decompile it back
>into C#, or vice versa (if you avoid newer C# features that aren't
>supported in VB.NET yet).


VB is not called VB.NET anymore.

When one writes code in VB, then compiles it into IL, one
can't but avoid newer C# features that aren't supported in
VB yet!

There also are features in VB not supported in C#.

"Visual Basic is a full-fledged modern object-oriented
language with many unique features, such as static
typing where possible but dynamic typing where
necessary, declarative event handling, deep XML
integration with optional layered XSD types, highly
expressive query comprehension syntax, type inference,
etc. etc. This makes Visual Basic actually more
interesting to researchers and practitioners than the
"popular" static languages such as Java, C# and dynamic
languages such as Ruby or JavaScript."

Erik Meijer

 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      06-09-2011
Michael Wojcik <(E-Mail Removed)> writes:
>LibreOffice: A fork of the OOo code, which does not have a great track
>record. Consider CVE-2010-3450 through -3454, etc. And while those
>CVEs don't list LibreOffice among vulnerable products, the SuSE
>LibreOffice update claims it's vulnerable (see [1]). I suspect the
>relative lack of official vulnerability reports for LibreOffice is
>because they're generally reported against OOo instead. And since LO
>has significant additional features on top of the OOo base, it has a
>lot more room for additional mistakes.


So, where is my Java Office Suite?

1997 Lotus wrote an Office Suite in Java, but it has been withdrawn.

 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      06-09-2011
On 6/8/2011 8:41 PM, Stefan Ram wrote:
> Michael Wojcik<(E-Mail Removed)> writes:
>> LibreOffice: A fork of the OOo code, which does not have a great track
>> record. Consider CVE-2010-3450 through -3454, etc. And while those
>> CVEs don't list LibreOffice among vulnerable products, the SuSE
>> LibreOffice update claims it's vulnerable (see [1]). I suspect the
>> relative lack of official vulnerability reports for LibreOffice is
>> because they're generally reported against OOo instead. And since LO
>> has significant additional features on top of the OOo base, it has a
>> lot more room for additional mistakes.

>
> So, where is my Java Office Suite?
>
> 1997 Lotus wrote an Office Suite in Java, but it has been withdrawn.
>


OpenOffice is written partly in Java...

I am not sure what or how much, as personally I have not looked at its code.
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      06-09-2011
On 11-06-09 12:38 AM, Stefan Ram wrote:
> Michael Wojcik <(E-Mail Removed)> writes:
>> VB.NET is in many ways closer to C# than it is to historical BASIC.
>> It's trivial to compile VB.NET into MSIL and then decompile it back
>> into C#, or vice versa (if you avoid newer C# features that aren't
>> supported in VB.NET yet).

>
> VB is not called VB.NET anymore.


That's true, and I guess it hasn't officially ever been VB.NET except
for the 2003 version. In the real world, though, a lot of coding still
happens in classic VB. I've had to do fairly extensive work the past few
years in VB6, work which is not readily possible in VB (.NET). For ease
of discussion I'll often refer to VB7 and later as VB.NET, and I'm not
alone in this.

> When one writes code in VB, then compiles it into IL, one
> can't but avoid newer C# features that aren't supported in
> VB yet!
>
> There also are features in VB not supported in C#.
>
> "Visual Basic is a full-fledged modern object-oriented
> language with many unique features, such as static
> typing where possible but dynamic typing where
> necessary, declarative event handling, deep XML
> integration with optional layered XSD types, highly
> expressive query comprehension syntax, type inference,
> etc. etc. This makes Visual Basic actually more
> interesting to researchers and practitioners than the
> "popular" static languages such as Java, C# and dynamic
> languages such as Ruby or JavaScript."
>
> Erik Meijer
>

Those are 2007 comments if I'm not mistaken. I'm using C# 4.0 in a
current WPF project, and I'm not sure that there's any of those features
that I'm _not_ using right now. Microsoft has very rapid development
cycles for its languages (as you know), and while that's sometimes a
PITA it's often a bonus. One side-effect of that is that if a given
version of VB has something cool, and a given version of C# doesn't,
then most of the time the next version of C# will.

Recall that C# 4.0 is mostly about dynamic features.

OT for CLJP: writing desktop apps in C# 4.0 and WPF (XAML heavy) is yet
another eye-opener for me. I'm mostly a Java SE/Java EE guy and so every
time I get a chance to do some pro work in C# it's refreshing.
Particularly GUI work. To this day if I wanted a GUI in the Java world
I'd go with a web app. If there's one thing MS seems to have gotten
right forever, and Java has struggled with, it's desktop apps and all
the tooling for it.

And I hate to say it but ever since I started using C# (with C# 2.0 in
my case, I barely scratched the surface of 1.0) it's always struck me as
being a jump or two ahead of Java. Most of that I attribute to the
dynamicism of the Microsoft language factory, contrasted to the problems
of the JSR process. But it's certainly been the case for me that it just
seems to be easier to get things done with C# than with Java, version by
version. Particularly with desktop apps.

This is core language mind you. I think Java EE on the other hand
generally has had a definite edge over anything that Microsoft has
produced, and Java EE 6 is more of the same. But not necessarily by much
- Java web apps got a jump on MS in particular with JSF, but a few years
later MS levelled the playing field with ASP.NET MVC, and for a whole
spectrum of web apps these days I'd toss a coin to choose between JSF
2.x and ASP.NET MVC 2 or 3.

AHS
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      06-10-2011
Arved Sandstrom <(E-Mail Removed)> writes:
>OT for CLJP: writing desktop apps in C# 4.0 and WPF (XAML heavy) is yet
>another eye-opener for me. I'm mostly a Java SE/Java EE guy and so every
>time I get a chance to do some pro work in C# it's refreshing.
>Particularly GUI work.


Last time I looked, the library did not even offered me
lay-out managers, and wanted me to specify the component
geometry in some screen unit.

I tried to code my way around this and build GUIs without a
hard-coded geometry.

For example, when I tried to create a form with a button,
an input field and an output field, I had to set its size
/manually/ (what a disgust, just look at the 5!):

form.Size = new System.Drawing.Size( button.Size.Width, 5 * input.Size.Height )

, and there was no default layout mangager which would do
this for me. But maybe I just did not known the most elegant
way to do this in C#?

 
Reply With Quote
 
Michael Wojcik
Guest
Posts: n/a
 
      06-11-2011
Arved Sandstrom wrote:
>
> I might note that I ran across one comment by an Axis 2 C developer
> where he said that the model to be followed was
>
> "typedef done inside the header and the struct declaration is in
> source...in a case you still want to move the struct to the header (it
> is not a much recommended approach in c programming) ... [Ed. How-To
> description of procedure follows]"
>
> Maybe I missed something in my years away from C, but those
> recommendations were new to me.


His description's not quite right, but incomplete structure
declarations are an important aspect of encapsulation in C.

Ignore any mention of "typedef" for a moment. typedef is a misnomer,
since it doesn't define a type, just an alias for an existing type.
(It's also of questionable utility. Some people think it's useful for
defining complex function-pointer types; I say if you don't understand
C's function-pointer syntax, don't write C code.)

In C, new types are defined using the struct keyword (and sometimes
union, but that's really just a specialized struct). The struct
keyword can do either or both of two things:

- define a structure type
- introduce a type name into the struct-tag namespace

The former is necessary if you want to inspect the contents of an
object of the type, evaluate its size or the size of the type, etc.
But it is not necessary to define certain derivative types, such as
the const-qualified equivalent type, or the associated pointer type.

The latter is what lets you encapsulate. In a header, you provide an
incomplete structure declaration and an API that uses the pointer type
derived from it:

struct foo;
struct foo *CreateFoo();
DoThingToFoo(struct foo *, ...);
PureFunctionOnFoo(const struct foo *, ...);
DeleteFoo(struct foo *);

Consumers of your API have no access to the implementation of struct
foo, so they're insulated from any changes to it. And since struct foo
* is a perfectly good object pointer, they can do whatever they'd do
with any other pointer, except dereference it.

(You can of course wrap "struct foo" in a typedef, if the people who
use your API are too lazy to type the word "struct".)

Note the initial "struct foo;" is necessary. Otherwise the use of an
unknown "struct foo" in the declarations of the API would only
introduce the type name in "prototype scope", which ends at the end of
each declaration. Prototype scope is basically useless.

This is a useful and fairly widely used technique - though not nearly
as widely as it should be. Of course, the API has to provide for
whatever its consumers need, since the consumers don't have direct
access to the contents of the structure, can't allocate or copy one, etc.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments