vs 47.3 on my workstation). And it does more stuff -- a lot of the add-on packages for Java, including all of their J2EE crap, parellels
I am guessing you are stating that Java has more stuff since.NET does not have J2EE anything. Microsoft cannot have anything past the 1.1 J2SE framework due to license conflicts with Sun. Also, the J2EE framework is a seperate package from the standard java runtime (J2SE).
CD is trivial, and most Windows Update and XP users have it already.
I have XP and had to download the.NET framework from Windows Update to get it.
What's cool about.NET is that the IDE supports all sorts of really useful data transformation and reporting mechanisms using SQL/XML/etc built right in...no rolling your own data access methods (though I end up doing it anyway).
This is covered by JDO in Java. Theres also a really nice opensource reporting library call JasperReports. Along with that theres iReports which is an opensource IDE for creating JasperReports.
3).NET is better than Java for apps that will always be used on a Windows PC, because:
- It has a much faster graphics interface, while maintaining a robust graphics toolkit.
See the SWT project. It uses native graphics rendering and widgets in Java.
- It interoperates quickly and pretty thoroughly with current COM APIs, and wraps up nicely for use in non-.NET apps
SWT has OLE/ActiveX support.
- The Studio environment is faster to work with and has a more mature debugger than any Java IDE I've seen, including Netbeans
Eclipse project works real well. Its very fast (again, uses SWT to render widgets) and has a very mature debugger.
- ADO.NET is pretty nicely done, and things like DataAdapters parellel structures I always end up writing in Java anyway.
Its JDO in Java world.
Anyway, the runtime filesize argument is just crap. The java guys need to get that GUI speed up to par or.NET's going to roll right over them.
Yes, check out Eclipse (www.eclipse.org). I have been using SWT in combination with GCJ to create native windows applications that dust anything created in VB (though C/C++ apps are a couple milliseconds quicker).
Eight months ago I'd have never said this, but Java isn't my favorite language anymore. C# is.
I liked.NET. It has some interesting concepts that will spur Sun to improve Java. I think SharpDevelop is a nice IDE worth checking out for anyone wanting to get into.NET without buying Visual Studio. Also of interest is the Mono project (www.go-mono.org) which is a open source implementation of.NET framework.
And even association with the vile and repugnant Microsoft isn't enough to sour it.
I think both Microsoft and Sun suck at being at the helm of both languages. Borland does a better job with C/C++ over Microsoft and IBM does better work with Java compared to Sun.
The.Net framework is ~22 megs. That's not that big, really. I know the JDK is almost 100 megs, and that's only a 5 min download.
The.NET framework does not include the compiler and associated development pieces that come with the JDK. A better comparison is the.NET framework vs. Java JRE (Java Runtime Environment). And I have absolutely no idea where you found a JDK at 100M in size! The latest is less than 30M.
Sun is just trying to place Java in direct competition with.Net. The next version of Windows will include.Net preinstalled. Having java installed on those computers makes Java an option. Both.Net and Java also differ from Flash in that they are pretty large downloads. Since most people still use dial-up the 10 meg downloads for Java or.Net seem a bit much.
We ported some of our internal Java business applications to C# for use with Mono, and emperical results already suggest the solution is several times faster than the Java code.
You could have saved yourself some porting by just compiling your java code with GCJ. GCJ allows you to compile your java byte code to native executables.
Porting the UI to Gtk# was more difficult, but we find the Gtk# code more maintainable and the UI, along with the Gtk+ WIMP [sourceforge.net] plugin integrates much more nicely with Windows than SWING.
Use SWT with Java. SWT uses Windows native widgets on Windows or GTK on Linux.
We also ported some of our backend tools for use with Mono. In use with the newly released Mono JIT runtime, Mini [ximian.com], we've achieved some truly stunning results. It turns out that some of the optimisations in the new JIT are better than those used by GCC, so once the code is loaded in memory, it performs better than raw C code.
Either your telling a big lie or dont have your facts straight. Unless you can show hard facts your not going to sway anyone into believing interpreted code outperformed compiled.
it has to be said that Mono is the real answer to Java performance.
Yes, if you dont mind porting existing working code.
Being Open Source, we can also contribute back to the runtime to make it better suit our needs. It also plays nicely with RedHat 9's NPTL threading implementation, which is more than I can say for the current crop of Java JREs.
What is exactly wrong with Java's use of native threads on Linux boxes?
In particular, performance and correctness of Swing on X11 and Macintosh are iffy: for example, window management is broken on X11, antialiasing makes lines disappear on Macintosh, and graphics can crawl to a halt in the presence of transparency on both X11 and Macintosh.
Ive used Swing in both X11 and on a Mac. I have seen none of the issues you are speaking of. Maybe when it first came out there were bugs but these must have been fixed.
loss of performance with the current obsession on over-inheritence and Java-style interpreted/P-code software overall.
Most companies see the small performance loss from using object oriented languages does not compare to the loss in man hours maintaining non-OOP code. OOP code scales better when that small application gets larger. Code reuse is simpler and can aid in quicker development of other applications with similiar functionality in the future.
The "vanilla unix" does not exist anymore so its not really an issue. The original idea of byte-code compatiblity was lost when unix commercialized. This spurred the development of a language like Java which allows code to be cross-platform. Writing in ANSI C would be another way of doing this if only it was implemented the same across the Unixes and the hardware remained a constant. That will never happen.
Add to this GPL/OS that slashes meaningful business value from well engineered software components
I think that there are many well engineered software components under the GPL and could give plenty of examples. These components required the experience and time of many programmers. By sharing this codebase IT departments do not have to hire dozens of programmers to create a similiar product.
You may be a "professional" developer, but I think you should avoid any position where you would have decisions on the direction of what technology is used within your company until you come into the realization of the economic savings of GPL code and the reasoning behind object oriented languages. These subjects are generally covered in most computer science programs at most universitys.
I find Indians to be very pragmatic. Windows is the most popular OS, so that's what they learn and use.
Yes, I agree that this is a product of many schools in India: go with whats most popular. It makes sense to a degree. Why, logically, go with what is not doing the best in the market? There are more jobs out there for Microsoft products than there is for Linux. If you had students and you wanted them to get jobs in the extreme job markets which exists in Asia what would you go with?
Having a mass number of people does not mean more inginuity oddly enough. If so China would run the computer software industry. Asian programmers, IMOH, are less likely to take the chances thier North American or Europeans counterparts would take. There is good and bad with that. Its all a matter of opinion.
The "dont buy it" idea will not work. Microsoft owns 99% of home PCs. If they make Palladium a required part of Windows ( like Internet Explorer ) PC vendors will be forced to comply. I really doubt Intel or even AMD are going to put up that much of a fight to stop this.
Palladium is an open source killer. Thats its purpose. Its security for Microsoft.
Distros are getting pretty weighty. RedHat 7.3, if I remember right, was on 3 CD's. To be fair RedHat does not install EVERYTHING on those 3 CD's. During the install you can choose to customize what pieces you want to install. But this customization is not a trivial matter. There are dependencies and ties and things you need that you had no idea you really needed. They need to make the install customization easier! I hate to mention it but a good wizard would be nice. This wizard, based on your persumed skill level, will allow you to customize at a level you are comfortable and capable of using. Just an idea.
Another way to increase performance: recompile the distro kernel source. I also use an AMD processor (older though) and have found that this solves the lag issues and some hardware oddities associated with using the distro's precompiled kernel.
X11 configuration seems to be issue #1 on installs. I had friends who were using Lindows or Mandrake bugging me over this on a constant basis. I really would like to see a community effort in resolving this. If we all sent in our mouse, monitor, etc configuration for X11 that works for us a community tool could build a database around this information. With this database a better (or smart) configuration tool could be built.
I have always found, as a rule of thumb, that you are better off recompiling the distro's kernel source after you install the distro. This seems to make the lag issue go away.
Agreed. The silliness comes from KDE users/developers who see that thier favorite desktop is being "brought down" to equal out to Gnome. They have ignorantly bitten on to a load of FUD launched by the core KDE development crew. Dont believe the hype. Before you respond, read up on what Redhat is ACTUALLY doing to KDE rather than what you have heard from some gossip source.
>>way creates a new object and then immediately throws it away; my way doesn't.
A java String instance is created whenever the java compiler encounters a string in double quotes. See the definition of String in O'Reilly's "Java In A Nutshell". That means in your example a new String was created and passed to parseInt. So no, you did not create a better Mouse Trap.
>>String has been overloaded as a class: it serves two purposes. The first is to store strings, and the second is to store string representations of other types of data (numbers, XML, whatever).
Oh lordy! First, there is no overloading in Java. Second, String is a class. It is used to either contain an array of unicode characters or operate on them. Thats it. There is no storage of XML or numbers or whatever. Just unicode characters.
>>it's storing a representation of the data, not a directly useable instance of the data. It's the difference between 5+4 (9) and "5" + "5" (55).
I dont know what this has to do with the price of cheese. Seriously, I am having troubles understanding your point.
>>but it shouldn't know about manipulating numbers stored in string format.
This is if you view parsing a number out of a string as manipulation.
I believe that value-added features in the future will bring about more purchases of Linux (with the understanding that these features only exists if you purchase the distro). Currently I believe saturating enough systems with your distro for free is a good start. Its up there with pissing into the wind. Oh wait... they are already doing this.
Not easier but rather just another way to do make the same Mouse trap. If we go by code size as being "easier" using parseInt requires a try/catch block being implemented since it throws a NumberFormatException. Both are used in different situations.
>> you want to add another data conversion for another type.
There are only 8 primitive data types: boolean, char, byte, short, int, long, float, and double. I know of no reason why that would ever change.
>>but you keep the information where it's supposed to be: with the data class, not with a representational storage class.
I do not understand your terminology. Please give a definition of what you call "data" classes and "storage" classes.
>>The following compiles perfectly on C#: 5.5f.ToString();//Float to string 5.5.ToString();//Doublt to string
In Java that simply looks like this: String.valueOf(5.5f); String.valueOf(5.5);
>>it's not String's place to have convertors in its interfaces.
What interfaces? String already has valueOf() functions for all primitive types. Adding the capability to get values out of Strings would be a nice feature.
>>On C#, it's as easy as: int a = Int.Parse(some_string);
In Java its pretty easy too: int a = new Integer(some_string).intValue();
I like the idea but I have always seen issues with implementation. Using your example of boxing how would you convert a float of 5.5 to a String? The String class already has some static methods that can do what you described:
String.valueOf(5.5f);
What would be nice is String having instance methods to get primitive values:
mystring.intValue();
I am no guru on C# and have not read that much into boxing.
As for the second part of your example you used the Collections API. I had this discussion on another thread that there are reasons you should use a primitive array over a Collections API when dealing with Java primitives: 1) Speed and 2) small memory footprint, 3) quick casting and copying. If you absolutely have to use a Collection just use the existing Number wrapper classes. But this should rarely arise (or atleast I can think of no good reason for doing this).
>>imutable objects almost made me lose my lunch.
Yeah, I ate light today. The talk about 4 byte charater Strings about made me sick. There is already String, StringBuffer, CharBuffer, and a CharSequence interface. I would love to see String represent old-school UTF-8 characters. Make another object that inherits from String that handles Unicode characters (UnicodeString). Put StringBuffer and CharBuffer functionality into String. Doing this you can drop CharSequence. The primitive type "char" would have to become 4 byte.
>>But there shouldn't be Bytes and bytes. Since we are dealing with objects, lets just use objects. Needless to say, we'll need to use objects representing byte arrays, and so forth.
JDK 1.4 introduced NIO. It has a ByteArray that wraps a true byte[] (actually it wraps a native void pointer in Buffer and just casts). When you deal with object I/O you should use the object streams: ObjectInputStream and ObjectOutputStream. There is a point of people complaining that they have to use the Number object wrappers (Byte, Integer, etc) around the primitive types to use them with the Collections API. This to me seems a rather moot point since you should use primitive arrays if you are only using primitive types since they are:
(1) easily made thread-safe, (2) are much quicker, and (3) do not hog up as much memory.
>> Seems that they tried to provide pseudo low level access to bytes, when it might have been better to go as far down in abstraction as C or as high as python.
Java sits in an odd place. Going in one way or the other leads to issues.
>>Which is bigger, 0xFE or 0x01?
if (0xFE > 0x01)
System.out.println("true");
else
System.out.println("false");
Result: true. 254 is to large a number for the Java primitive byte. The "If" condition blocks defaults to using ints.
>>When is 0x80 + 0x01 not 0x81?
Is this a riddle?
>>Having to manually compensate for two's complement representation gave me a big headache.
Keep asprin handy at all times. I keep a full bottle right next to my keyboard.
When I run Java on my Linux box it shows it running on 10+ processes (ps -Af | grep java).
>>Each process has its own VM. While this might have some advantages when it comes to controlling crashes and security, it also means each process has the initial overhead of starting the VM and the continuing overhead of the same duplicated code running in memory for each VM.
How about a single JVM (not process) that launches multiple Java programs? Thats not too hard to create.
>>jEdit, a popular Java text editor had to overcome this by attaching to an existing server process. Kludges like this shouldn't be necessary.
JEdit on Windows has a native launching program. Everything, including the plugins, run in this same JVM instance. JEdit can launch other Java programs from this instance using the Console. I have never heard of any kludges in Jedit.
>>Really there's no overwhelming reason the primitives can't remain as built-ins. They just need to behave in the same way as objects.
What do you mean in they have to behave like objects? So do they become garbage collected like regular objects? Can I serialize them? How about extend them? How does the equals() work?
Slashdot Mirror
vs 47.3 on my workstation). And it does more stuff -- a lot of the add-on packages for Java, including all of their J2EE crap, parellels
I am guessing you are stating that Java has more stuff since
CD is trivial, and most Windows Update and XP users have it already.
I have XP and had to download the
What's cool about
This is covered by JDO in Java. Theres also a really nice opensource reporting library call JasperReports. Along with that theres iReports which is an opensource IDE for creating JasperReports.
3)
- It has a much faster graphics interface, while maintaining a robust graphics toolkit.
See the SWT project. It uses native graphics rendering and widgets in Java.
- It interoperates quickly and pretty thoroughly with current COM APIs, and wraps up nicely for use in non-.NET apps
SWT has OLE/ActiveX support.
- The Studio environment is faster to work with and has a more mature debugger than any Java IDE I've seen, including Netbeans
Eclipse project works real well. Its very fast (again, uses SWT to render widgets) and has a very mature debugger.
- ADO.NET is pretty nicely done, and things like DataAdapters parellel structures I always end up writing in Java anyway.
Its JDO in Java world.
Anyway, the runtime filesize argument is just crap. The java guys need to get that GUI speed up to par or
Yes, check out Eclipse (www.eclipse.org). I have been using SWT in combination with GCJ to create native windows applications that dust anything created in VB (though C/C++ apps are a couple milliseconds quicker).
Eight months ago I'd have never said this, but Java isn't my favorite language anymore. C# is.
I liked
And even association with the vile and repugnant Microsoft isn't enough to sour it.
I think both Microsoft and Sun suck at being at the helm of both languages. Borland does a better job with C/C++ over Microsoft and IBM does better work with Java compared to Sun.
The
The
Sun is just trying to place Java in direct competition with .Net. The next version of Windows will include .Net preinstalled. Having java installed on those computers makes Java an option. Both .Net and Java also differ from Flash in that they are pretty large downloads. Since most people still use dial-up the 10 meg downloads for Java or .Net seem a bit much.
We ported some of our internal Java business applications to C# for use with Mono, and emperical results already suggest the solution is several times faster than the Java code.
You could have saved yourself some porting by just compiling your java code with GCJ. GCJ allows you to compile your java byte code to native executables.
Porting the UI to Gtk# was more difficult, but we find the Gtk# code more maintainable and the UI, along with the Gtk+ WIMP [sourceforge.net] plugin integrates much more nicely with Windows than SWING.
Use SWT with Java. SWT uses Windows native widgets on Windows or GTK on Linux.
We also ported some of our backend tools for use with Mono. In use with the newly released Mono JIT runtime, Mini [ximian.com], we've achieved some truly stunning results. It turns out that some of the optimisations in the new JIT are better than those used by GCC, so once the code is loaded in memory, it performs better than raw C code.
Either your telling a big lie or dont have your facts straight. Unless you can show hard facts your not going to sway anyone into believing interpreted code outperformed compiled.
it has to be said that Mono is the real answer to Java performance.
Yes, if you dont mind porting existing working code.
Being Open Source, we can also contribute back to the runtime to make it better suit our needs. It also plays nicely with RedHat 9's NPTL threading implementation, which is more than I can say for the current crop of Java JREs.
What is exactly wrong with Java's use of native threads on Linux boxes?
See GL4Java.
In particular, performance and correctness of Swing on X11 and Macintosh are iffy: for example, window management is broken on X11, antialiasing makes lines disappear on Macintosh, and graphics can crawl to a halt in the presence of transparency on both X11 and Macintosh.
Ive used Swing in both X11 and on a Mac. I have seen none of the issues you are speaking of. Maybe when it first came out there were bugs but these must have been fixed.
loss of performance with the current obsession on over-inheritence and Java-style interpreted/P-code software overall.
Most companies see the small performance loss from using object oriented languages does not compare to the loss in man hours maintaining non-OOP code. OOP code scales better when that small application gets larger. Code reuse is simpler and can aid in quicker development of other applications with similiar functionality in the future.
The "vanilla unix" does not exist anymore so its not really an issue. The original idea of byte-code compatiblity was lost when unix commercialized. This spurred the development of a language like Java which allows code to be cross-platform. Writing in ANSI C would be another way of doing this if only it was implemented the same across the Unixes and the hardware remained a constant. That will never happen.
Add to this GPL/OS that slashes meaningful business value from well engineered software components
I think that there are many well engineered software components under the GPL and could give plenty of examples. These components required the experience and time of many programmers. By sharing this codebase IT departments do not have to hire dozens of programmers to create a similiar product.
You may be a "professional" developer, but I think you should avoid any position where you would have decisions on the direction of what technology is used within your company until you come into the realization of the economic savings of GPL code and the reasoning behind object oriented languages. These subjects are generally covered in most computer science programs at most universitys.
I find Indians to be very pragmatic. Windows is the most popular OS, so that's what they learn and use.
Yes, I agree that this is a product of many schools in India: go with whats most popular. It makes sense to a degree. Why, logically, go with what is not doing the best in the market? There are more jobs out there for Microsoft products than there is for Linux. If you had students and you wanted them to get jobs in the extreme job markets which exists in Asia what would you go with?
Having a mass number of people does not mean more inginuity oddly enough. If so China would run the computer software industry. Asian programmers, IMOH, are less likely to take the chances thier North American or Europeans counterparts would take. There is good and bad with that. Its all a matter of opinion.
The "dont buy it" idea will not work. Microsoft owns 99% of home PCs. If they make Palladium a required part of Windows ( like Internet Explorer ) PC vendors will be forced to comply. I really doubt Intel or even AMD are going to put up that much of a fight to stop this.
Palladium is an open source killer. Thats its purpose. Its security for Microsoft.
Distros are getting pretty weighty. RedHat 7.3, if I remember right, was on 3 CD's. To be fair RedHat does not install EVERYTHING on those 3 CD's. During the install you can choose to customize what pieces you want to install. But this customization is not a trivial matter. There are dependencies and ties and things you need that you had no idea you really needed. They need to make the install customization easier! I hate to mention it but a good wizard would be nice. This wizard, based on your persumed skill level, will allow you to customize at a level you are comfortable and capable of using. Just an idea.
Another way to increase performance: recompile the distro kernel source. I also use an AMD processor (older though) and have found that this solves the lag issues and some hardware oddities associated with using the distro's precompiled kernel.
X11 configuration seems to be issue #1 on installs. I had friends who were using Lindows or Mandrake bugging me over this on a constant basis. I really would like to see a community effort in resolving this. If we all sent in our mouse, monitor, etc configuration for X11 that works for us a community tool could build a database around this information. With this database a better (or smart) configuration tool could be built.
I have always found, as a rule of thumb, that you are better off recompiling the distro's kernel source after you install the distro. This seems to make the lag issue go away.
Agreed. The silliness comes from KDE users/developers who see that thier favorite desktop is being "brought down" to equal out to Gnome. They have ignorantly bitten on to a load of FUD launched by the core KDE development crew. Dont believe the hype. Before you respond, read up on what Redhat is ACTUALLY doing to KDE rather than what you have heard from some gossip source.
You made some good points. I hate dragging threads out and will not be posting anymore.
>>way creates a new object and then immediately throws it away; my way doesn't.
A java String instance is created whenever the java compiler encounters a string in double quotes. See the definition of String in O'Reilly's "Java In A Nutshell". That means in your example a new String was created and passed to parseInt. So no, you did not create a better Mouse Trap.
>>String has been overloaded as a class: it serves two purposes. The first is to store strings, and the second is to store string representations of other types of data (numbers, XML, whatever).
Oh lordy! First, there is no overloading in Java. Second, String is a class. It is used to either contain an array of unicode characters or operate on them. Thats it. There is no storage of XML or numbers or whatever. Just unicode characters.
>>it's storing a representation of the data, not a directly useable instance of the data. It's the difference between 5+4 (9) and "5" + "5" (55).
I dont know what this has to do with the price of cheese. Seriously, I am having troubles understanding your point.
>>but it shouldn't know about manipulating numbers stored in string format.
This is if you view parsing a number out of a string as manipulation.
I believe that value-added features in the future will bring about more purchases of Linux (with the understanding that these features only exists if you purchase the distro). Currently I believe saturating enough systems with your distro for free is a good start. Its up there with pissing into the wind. Oh wait ... they are already doing this.
>>Under Java it's even easier that that:
Not easier but rather just another way to do make the same Mouse trap. If we go by code size as being "easier" using parseInt requires a try/catch block being implemented since it throws a NumberFormatException. Both are used in different situations.
>> you want to add another data conversion for another type.
There are only 8 primitive data types: boolean, char, byte, short, int, long, float, and double. I know of no reason why that would ever change.
>>but you keep the information where it's supposed to be: with the data class, not with a representational storage class.
I do not understand your terminology. Please give a definition of what you call "data" classes and "storage" classes.
>>The following compiles perfectly on C#:
;
5.5f.ToString();//Float to string
5.5.ToString();//Doublt to string
In Java that simply looks like this:
String.valueOf(5.5f);
String.valueOf(5.5)
>>it's not String's place to have convertors in its interfaces.
What interfaces? String already has valueOf() functions for all primitive types. Adding the capability to get values out of Strings would be a nice feature.
>>On C#, it's as easy as:
int a = Int.Parse(some_string);
In Java its pretty easy too:
int a = new Integer(some_string).intValue();
If my String idea was used you could write it:
int a = some_string.intValue();
>>Steal 'boxing' from C-flat.
I like the idea but I have always seen issues with implementation. Using your example of boxing how would you convert a float of 5.5 to a String? The String class already has some static methods that can do what you described:
String.valueOf(5.5f);
What would be nice is String having instance methods to get primitive values:
mystring.intValue();
I am no guru on C# and have not read that much into boxing.
As for the second part of your example you used the Collections API. I had this discussion on another thread that there are reasons you should use a primitive array over a Collections API when dealing with Java primitives: 1) Speed and 2) small memory footprint, 3) quick casting and copying. If you absolutely have to use a Collection just use the existing Number wrapper classes. But this should rarely arise (or atleast I can think of no good reason for doing this).
>>imutable objects almost made me lose my lunch.
Yeah, I ate light today. The talk about 4 byte charater Strings about made me sick. There is already String, StringBuffer, CharBuffer, and a CharSequence interface. I would love to see String represent old-school UTF-8 characters. Make another object that inherits from String that handles Unicode characters (UnicodeString). Put StringBuffer and CharBuffer functionality into String. Doing this you can drop CharSequence. The primitive type "char" would have to become 4 byte.
I said "ByteArray" but it should have been called "ByteBuffer". Thank goodness for javadoc.
>>But there shouldn't be Bytes and bytes. Since we are dealing with objects, lets just use objects. Needless to say, we'll need to use objects representing byte arrays, and so forth.
JDK 1.4 introduced NIO. It has a ByteArray that wraps a true byte[] (actually it wraps a native void pointer in Buffer and just casts). When you deal with object I/O you should use the object streams: ObjectInputStream and ObjectOutputStream. There is a point of people complaining that they have to use the Number object wrappers (Byte, Integer, etc) around the primitive types to use them with the Collections API. This to me seems a rather moot point since you should use primitive arrays if you are only using primitive types since they are:
(1) easily made thread-safe,
(2) are much quicker, and
(3) do not hog up as much memory.
>> Seems that they tried to provide pseudo low level access to bytes, when it might have been better to go as far down in abstraction as C or as high as python.
Java sits in an odd place. Going in one way or the other leads to issues.
>>Which is bigger, 0xFE or 0x01?
if (0xFE > 0x01)
System.out.println("true");
else
System.out.println("false");
Result: true. 254 is to large a number for the Java primitive byte. The "If" condition blocks defaults to using ints.
>>When is 0x80 + 0x01 not 0x81?
Is this a riddle?
>>Having to manually compensate for two's complement representation gave me a big headache.
Keep asprin handy at all times. I keep a full bottle right next to my keyboard.
>>Do you use the primitive data types directly when streaming?
Yes. See InputStream and OutputStream. They use primitive types.
>>Remember that the bytecode compiler and jvm are free to represent the data internally more efficiently if that is appropriate
Primitive types are as efficient as you can get since they compile into bytecode as thier byte size.
>> there's no reason that the bytestream classes can't assume 8 bit chunks, but I like the python-esque "everything as an object" approach.
There are many scripting languages that have taken this approach. Java is not a scripting language but rather interpreted. There is a difference.
>>And, yes I have done bitwise arithmetic in both C, Java and Python.
Thats good but I have no idea how this supports your point.
>>However, as long as we're talking about streaming data I/O, I would love to see bytes become unsigned.
Since you know bitwise arithmatic in Java you should know this is not an issue.
>>How many does a Java virtual machine run? One.
When I run Java on my Linux box it shows it running on 10+ processes (ps -Af | grep java).
>>Each process has its own VM. While this might have some advantages when it comes to controlling crashes and security, it also means each process has the initial overhead of starting the VM and the continuing overhead of the same duplicated code running in memory for each VM.
How about a single JVM (not process) that launches multiple Java programs? Thats not too hard to create.
>>jEdit, a popular Java text editor had to overcome this by attaching to an existing server process. Kludges like this shouldn't be necessary.
JEdit on Windows has a native launching program. Everything, including the plugins, run in this same JVM instance. JEdit can launch other Java programs from this instance using the Console. I have never heard of any kludges in Jedit.
>>Really there's no overwhelming reason the primitives can't remain as built-ins. They just need to behave in the same way as objects.
What do you mean in they have to behave like objects? So do they become garbage collected like regular objects? Can I serialize them? How about extend them? How does the equals() work?