Slashdot Mirror
Preview of Java 1.5
gafter writes "An early access prototype implementation of
the proposed new J2SE 1.5 language features is
available. The prototype includes
generics (JSR 14),
typesafe enums, varargs,
autoboxing, foreach loops, and static import
(JSR 201). In other words, all the new language features
planned for 1.5 except
metadata (JSR 175). The
prototype includes full sources for the compiler,
written in the extended language. You can download the prototype from
java.sun.com.
It requires J2SE 1.4.1 and provides some examples of how to use the new language constructs. The prototype includes an experimental type
system (variant type parameters)
for Generic Java that is being considered
for Tiger (1.5) based on a paper by
Igarashi and
Viroli at ECOOP 2002 .
Comments and votes for the new type system are
being gathered at
bugParade."
Native compilers have been available forever but they rarely gain you enough over JIT to justify the lack of crossplatform portability. If you are running a J2EE app as middleware for a huge ecomerce or CRM system, etc then sure recompile to native code, but for other things it doesn't make sense when the JIT compilers are 99% effective. The biggest thing slowing JAVA down is the lack of a decent GUI framework.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
I'm surprised to see that there are still people out there which use 'interpreter' argument...
Anyway, there is a plenty of native compilers for java. I'm not sure if you have heard about certain compiler from free software group called Antilope or something like this - I think it is called gcc. They have a frontend for java, gcj, which compiles java source/bytecode to same intermediate stage as other compilers, thus sharing optimizing backed. If you don't care about paying few bucks, JET is very good compiler, written specifically for java, supporting 1.4.1. There is also few others, but I can tell only about these two from my experience.
Both these compilers are available for few years now. Problem is not with lack of native compilers, or performance of java in mixed mode offerred by Sun hotspot - problem is with mindset of poster. If you are not willing to use java - no problem. But please say it is 'religious' - everybody will agree with you, as you can have any beliefs you want. But do not try to back up religious statements with fake arguments.
(Excuse my whoring, but Sun's link to GJ was 404.)
When I moderate, I only use "-1, Overrated". That way, I never get meta-moderated!
The only complaint I have is the new format for the for loop... for (int x : b) isnt really easy to read. foreach x in b or something like that, while a little more verbose would be a cleaner
Introducing new keywords may break old programs if they have a variable with a name identical to that of one of the new keywords. Using the colon sidesteps this.
Click on the link!
isn't syntactic sugaring all about making code more readable? I think boxing , generics, typesafe enums, static imports make the java language more simple to use.
It's just looking over the fence to the "sibling" languages (c++, c#) and copy what they do better.
JPanel jp = new JPanel();
JComponent jc = jp;
works just fine (just tested in 1.4.1). I imagine the same applies to the second one too. Also, if this wasn't the case generics wouldn't help in this code. Generics only remove the need to cast when extracting an object from a container, if I understand things correctly.
If you don't know anything about it SHUT UP!
.NET:
Java:
-Java as a language is not a standard but doesn't change much at ALL.
-Every API is developped through the Java Community Process
-C# + CLR is standardized (yes only a language and a VM)
-Other API's are NOT standardized and are in full control of Microsoft
I think that mono will have some major problems in the future. Sure they can implement C# and CLR, but they virtually have to reengineer all other API's, because there are no formal specs available.
GCJ?
And as the 1.5 compiles to compatable byte code, can automaticly use the new 1.5 features (with the exeception of new classes.
Wow, I should not post when knackered.
Look here for more info. My guess is Sun is brewing something with the next edition of SunONE and Forte. Notice how Sun is targetting there new tool at VB users.
Its possible these features were added to java 1.5 so Forte can have a VB like ide to generate java code easier. After all, enums make things easier to read and are essential for new programmers to read your code.
Competition is great and I believe a great RAD and ide that is based on a fairly good langauge will give
http://saveie6.com/
I believe one of the things Sun tried to get at was to make Java development easier. It's something they're working on across the board, as this article notes.
Without seeing (in the Java source code) how the templates are implemented I can't say that I agree or disagree with your statement that they will be inefficient, though I'm inclined to disagree based on your example. Templates or not, objects are going to be stored the same way. The difference is how those objects are retrieved. Right now you have to cast everything coming out of an ArrayList (unless the Object reference is sufficient)...not only is that being moved to the language but you also gain compile-time type checking. That will only serve to reduce errors and make the software more reliable. Templates are optional anyway - you don't have to use them. I'm looking forward to them.
I don't think you're ever going to see VM sharing. If applications can share VMs then one rogue app could bring down other apps by trashing the VM (never supposed to happen) or by poor thread management.
Either way you look at it, it's a good year to finally be going to JavaOne...
for an out-of-the-box solution. To deply an app, just copy the app into the deployment directly. To configure, fire up a browser and point it at port 8080 (I think).
Haven't come across many app servers as simple as that.
"Without seeing (in the Java source code) how the templates are implemented I can't say that I agree or disagree with your statement that they will be inefficient, though I'm inclined to disagree based on your example."
:-(
.NET you just store a 32bit value in an array, which is a single operation on most processors.
.NET templates will create a different class for each primitive type, so that primitive types will indeed be stored in their corresponding primitive arrays without creating objects on the heap. For classes, the .NET implementation behaves similar to the java implementation: There is only one internal class created for all reference types.
.NET does it, by the way.
Slashcode swallowed some brackets even though I was in text mode
What I mean is the following: If you create for example an ArrayList of ints, the most efficient way to store these ints internally would obviously be an int[] and not an Object[]. But even though java uses templates, it still stores primitive types such as int in an Object[], so there is a huge temporary object creation overhead. Whenever you store an int in your IntArrayList, a new Integer object is created on the heap and an old Integer object has to be garbage collected. In
The
"Templates or not, objects are going to be stored the same way. The difference is how those objects are retrieved. Right now you have to cast everything coming out of an ArrayList (unless the Object reference is sufficient)...not only is that being moved to the language but you also gain compile-time type checking. That will only serve to reduce errors and make the software more reliable. Templates are optional anyway - you don't have to use them. I'm looking forward to them."
Me too. It is not that I dislike the new features. I just think that they could have been implemented better, faster and earlier.
"I don't think you're ever going to see VM sharing. If applications can share VMs then one rogue app could bring down other apps by trashing the VM (never supposed to happen) or by poor thread management."
VM sharing does not mean that all java programs must run in one process. But for most desktop applications this would make a lot of sense. You are right about the thread management, but you could always restrict the number of threads an application can create. Just have a nice XML file which describes how much resources each application may allocate. That is the way
If sun will not do VM sharing, you will never see decent client applications written in java. Just think about it: for each java application you start, the whole swing library has to be JIT-Compiled anew. What a huge waste of processing power!
Private property is the central institution of a free society (David Friedman)
JavaScript has nothing to do with Java, other than their similiar names. JavaScript, originally LiveScript, "was renamed by Netscape marketers who licenced the name to ride Java's Buzz" (Wired, July 2002, pg. 61). Javascript is actually an offshoot that sprung from both C++ and ANSI C (C89). JScript and ECMA Script sprung from Javascript.
Slashdot: Playing Favorites Since 1997
I am working with a large bank at the moment, one of the largest in the world and they have largely junked Java, except for running browser applets.
They liked Java, the class libraries were great but, sorry, it is too slow. I'm not talking about incompetent coders. They even had Sun in looking at some of the apps. The end result was a customised virtual machine - but it was still too slow and the incompatibilities were a killer. The VM had to work identically across the bank's generations of systems from different vendors. One gotcha, IIRC, was synchronisation, making it difficult to run a JVM across processors and to exploit them properly for performance.
End result was a switch back to C++ for back end apps. Java could still be used but only for non-critical front-end stuff. The bank may consider C#, but it seems that Java has had its day.
Maybe this sounds like a troll, but Sun should release their control of the Standard. This will slow things down, think how long it takes to get stuff into C++, but that stability gives everyone room to think as to whether a change is really necessary.
I don't like the idea of C# but at least MS handed it over to ECMA.
Actualy, try looking at Jython
Sure, for small programs its not perfect (as you'd have to still run the VM), but this way you can integrate Java applications and use Python to script these applications.
Avoid this crap. Go C++, or better yet Eiffel with C, and stop kidding yourself that Java getting a shiny "for" syntax is a reason for celebration.
Hm,
can you give in your wisdome a hint which library and toolset to use to let my Eifel/C program run on my YOPY, on my Mac and on my Windows PC?
I mean: there is an Eiffel compiler for YOPY, isnt it? And its GUI library is compatible with the one on my Mac, surely it is?
Tzzz.
Java neither has all the features C++ has, nor does C++ have all the features Java has.
E.G. multithreading support and object level synchronization. Java: + C++: -
E.G. garbage collection. Java: + C++: -
Should I continue? RMI? Serialization? Reflection?
When the STL came out, we had the FIRST!! standardized library for C++. Even the iostreams libaries still are platform depended today!
When Java came out, everything thinkable was inside of the core libraries. Networking, multithreading database access, directory services and so on.
Java might suck as a language, I myself said that often enough when I switched from C++ to Java. But that was 8 years ago. Java has improved and does no longer suck, especially with generics. However: the java libs allways where great, the documentation outstanding, the sourcecode available in case of uncertainty. How is that with C++? Standard threading? Since when? Standard GUI library?
C++ is a great language where the libraries and standards came far to late and where even in our days two compilers might get different ideas about your code. Portability is only possible if you restrict yourself to only a subset of C++
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Ah, but Java's two for-iterator loops are slightly different. The 'foreach' IIRC provides you with a single variale that points to successive items in your collection...it does not provide you an iterator. This means you can traverse the items in the collection but you can't filter them or change the collection itself.
The old 'for' syntax is still necessary if you want to actually change the collection, eg to filter out objects from the collection, or to insert objects in specific places. The old syntax is more error-prone (since Iterator.next() is usually called in the body of your for loop, are you sure its being called *every* time???)
So both for syntaxes have inherent advantages and disadvantages. So they're both worthwhile to have around.
Practice Kind Randomness and Beautiful Acts of Nonsense.
ISO C++ was standardized in 1998. GCC 3.x (came out in 2001) supported every language feature except "export" which is now believed to be a mis-feature. All the compilers I use on a daily basis (GCC 3.2.2 and Intel C++ 7.1) compile every bit of code I've thrown at it.
A deep unwavering belief is a sure sign you're missing something...
No.
Sun are apparently looking at the work that Apple did to provide this functionality with the Apple implementation of 1.4, but it's not likely to be in 1.5 (see this chat transcript for the official line. Maybe 1.6 for non-Apple VMs?
The changes mentioned in the other products have been integrated into JSR-14. So while it would appear that maybe nothing that big has happened, you in fact have a useful 1.5 preview.
Scout's honor.
Cleaning up the core libraries should never mean rearranging them according to some fleeting sense of pure aesthetics. Even a cleaned-up Java has to provide some amount of backward compatibility for existing code. Changing the collections' package just doesn't make anyone's job easier.
"The deluded are always filled with absolutes. The rest of us have to live with ambiguity." - Aristoi, Walter Jon Willia
I don't like the idea of C# but at least MS handed it over to ECMA.
Microsoft has handed C# to the ECMA, not .NET.
The language is insignificant compared the the framework, that is the large set of APIs, libraries, documenation, and endorsements that come with the language.
C# being offered to the ECMA is a marketing ploy.
Look at ECMAScript. It's a standard isn't it? Now how come we still have to be careful which browser we're in when we write JavaScript/JScript for the web?
It does not matter what ECMA says. Microsoft will always have the de-facto standard on C#, because they produce the environment Visual Studio .NET used by most professionals, they distribute the most runtimes/CLR, they produce the documenation, they have the marketing muscle ( $40B in the bank ).
Don't fall for this cheap trick.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW