If I write a binary file and write out the bits to be in the form of LITTLE ENDIAN and I place this binary file on to the disc. Will the JVM read back the file using LITTLE ENDIAN or will it use Big Endian?
> If I write a binary file and write out the bits to be in the form of LITTLE ENDIAN and I place this binary file on to the disc. Will the JVM read back the file using LITTLE ENDIAN or will it use Big Endian?
When you write a binary file, you'll probably be using something
like DataOutputStream, which has methods like writeInt(integer).
That class has a defined order for the data file, and that order
is the same on all platforms. I forget if it's big-endian or
little-endian, but the important point is that you don't have to
worry about it, because its the same everywhere.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
DataInputStream on the Windows JVM will read in a stream using Big Endian, even if the file was written using Little Endian, do you know if there is a VM spec for the players? If so maybe we can purchase it or is it part of a JSR number?
> Hello Bill,
> DataInputStream on the Windows JVM will read in a stream using Big Endian, even if the file was written using Little Endian,
If what you mean is that you can use a C program to write an integer into
a data file in little endian order, then that integer will be interpreted
as big endian by a Java program running on any machine, then you're probably
right. (Java insulates me from worrying about big- vs. little-endian, and
it's been over a decade since I've done C programming in earnest, so I've
actually forgotten which is big endian and which is little endian. That's
the only reason I say "probably" above.)
What's important is that if you write a data file with a DataOutputStream
on any platform, then you can read it back with a DataInputStream on any
platform and get the correct results. Here's what DataInputStream
A data input stream lets an application read primitive Java data
types from an underlying input stream in a machine-independent
The specification of the readInt method (which comes from the
DataInput interface) is quite explicit:
Reads four input bytes and returns an int value. Let a be the
first byte read, b be the second byte, c be the third byte,
and d be the fourth byte. The value returned is:
(((a & 0xff) << 24) | ((b & 0xff) << 16) |
((c & 0xff) << 8) | (d & 0xff))
For app developers, the rule is really simple: The Java programmer
never needs to worry about endian-ness. The *only* time you have to
think about it is if you're writing a program in C, or some other
language that doesn't insulate you from such low-level concerns.
> do you know if there is a VM spec for the players? If so maybe we can purchase it or is it part of a JSR number?
Just a bit of vocabulary: The VM is just part of the overall platform.
DataInputStream and DataOutputStream aren't part of the VM, but they
are part of the platform.
Anyway, yes, there is a specification, available on the web.
Applications are to be authored to Personal Basis Profile
1.0, which is JSR 129. It includes other JSRs, like Foundation Profile 1.0
and CDC 1.0, and these eventually reference the VM specification. You
can get all of these from http://jcp.org.
> Thank you,
> [Message sent by forum member 'bddeveloper' (bddeveloper)]
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
Thank you for the quick reply. The readInt method in DataInput is defined by JSR 129 and this definition does define the order of the bits. In this case it is always going to be Big Endian it is the same for JD1.3+. This tells us regardless of the underlining hardware the language will read it in as Big Endian. Thank you for point that out. We should have re-read the spec in greater [b]detail[/b].
As far as the differences between the JVM and API I'll use a [b]classic[/b] example of a JVM specific issue with performance that is not clarified in the API Spec. Fortunately the documentation is the same for JSR 129 as it is for JDK 1.3 and since there is a web link to the spec for JDK 1.3 I'll refer to it here:(http://java.sun.com/j2se/1.3/docs/api/) If you read the spec for java.lang.String you will find nothing about how the JVM treats this object. If you do the following:
String helloTest = "Hello ";
helloTest += "Bill " + " how are you " + "today?\n";
helloTest += "I hope " + "you are having " + "a good day.";
This will have a performance hit verse using StringBuffer. For reference we have several jdk 1.2 and 1.3 performance books at our disposal and recommend the following book (http://www.amazon.com/Java-Performance-Tuning-Jack-Shirazi/dp/0596000154), along with http://www.bookpool.com/sm/0201432943
The reason for the performance hit is a new String object is created with every concatenation after 2 have been created. The API does not define this information, however it is extremely important to know. This is why I ask about the JVM implementation of these players and why it is important to know the spec. If it is not plublic that is understandable but at least which spec to buy is good to know.
We have read the books I've recomend and now we will fully read the API for JSR 129's Final Release. Hopefully we'll be able to ask questions that are more focused.
> The reason for the performance hit is a new String
> object is created with every concatenation after 2
> have been created. The API does not define this
> information, however it is extremely important to
> know. This is why I ask about the JVM implementation
> of these players and why it is important to know the
> spec. If it is not plublic that is understandable but
> at least which spec to buy is good to know.
You have chose very bad example.
First, only 2 concatenations will be performed in the code you have posted. Your code is equivalent of
String helloTest = "Hello ";
helloTest = (new StringBuilder(String.valueOf(helloTest))).append("Bill how are you today?\n").toString();
helloTest = (new StringBuilder(String.valueOf(helloTest))).append("I hope you are having a good day.").toString();
This is because you have used literals on the same line and they are concatenated at compilation level, not at runtime.
Regardless of that, fact that StringBuilder/Buffer is used is not defined by neither API nor JVM - it is defined somewhere between compiler and java language spec. Check out
Exact way of how it is done is determined by your compiler, not JVM version.
There are some points which should be checked against specific JVM implementations - level of dynamic optimalizations, behaviour of garbage collector, memory constraints, etc. But don't try to over-optimize on trivial cases, in 99% cases time is better spent on improving the logic/algorithms. Low level optimalizations can come at very end, when you are already profiling ready code against specific JVM (and if you target multiple JVMs, which will be probably the case with BD-J, you will end up profiling on multiple architectures).
Thank you I will be more realistic in all my examples to ensure I do not confuse or mislead.
As far as performance in BD-J application I would have to say a tremendous amount of work needs to be done and it must be the top priority. If someone is coming from HD DVD and they would like to create a translucent menu that fades in and then has a scrolling chapters area in BD-J they would find that after all their work the BD-J application will just not perform and there is no way to improve the performance because the foundation in which they've built their menu on cannot keep up and we are unsure of when the foundations will be able to perform at the level of what HD DVD authors are used to.
Therefore performance should be the most important item when building a BD-J application otherwise BD-J will end up as something used for bonus features. DVD Authors of the world will simply use HDMV mode, because it is faster in performance, easier to learn and 100% reliable on all players, not to mention there is already one lawsuit over specific BD-J titles that do not play in certain players, due to performance issues, if this lawsuit is successful it will have an impact on professional authors thinking about implementing BD-J.
FYI: The lawsuit is in reguards to non-update of BD+ on the player... not performance.
Thank you for the correction.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.