Slashdot Mirror
Summary of JDK1.5 Language Changes
An anonymous reader writes "Over at java.sun.com, there's an informative article about the new features in JDK1.5. Some of the changes like generics are nice and should make some things easier. Some of the enhancements to me are purely sugar, like enumerators. When it comes down to it, once the code is compiled, it's the same. The thing I hope is, some of this new syntactic sugar doesn't result in more obfuscated code. Unlike some people, I feel using programming shorthand leads to increased maintenance. This is especially true when you have to debug a complex application."
enumerators are much better than just plain ints. Even though they may compile to the same thing, the compiler can do a little more checking on the enumerators, since it know the valid ranges for the enumerator so you don't have to explicitly check the range. You do check to make sure you get passed a valid value for all your int-as-enumerators? Don't you?
I worked in Java a few years ago and haven't kept up much with development kits, etc. The language I could pop right back into, but could use some advice on good/affordable IDE.
A feeling of having made the same mistake before: Deja Foobar
i love java, and i'm excited for the new version to arrive
I think Generics is going to be a really nice long awaited feature. I am wondering if this type of change is going to require a modification to the bytecode specification. If that is the case, then new code bytecodes will not work with older bytecodes. Does anyone think that Sun can pull this feature off without a change to the bytecode spec? Would this be major compiler change?
...he's forcing improvements in Java.
668: Neighbour of the Beast
I agree. This is why I never create my own functions or methods. Evey program should be just one big function.
... for the things remaining the same.
It seems to me that the suggested syntax for generics simply moves the pain from casting at retrieval time to casting at declaration time. That is, dynamic typing is still far away. Sigh.
-- Let's go Viridian.
Unlike some people, I feel using programming shorthand leads to increased maintenance.
I hope you never have to look at any PHP; you'll go blind.
jack's bicycle is music to my ears
The metadata, auto-boxing, enhanced iteration looks like catch up with C#'s attributes, foreach, etc.
Where are true properties though?
Typesafe enums. That alone makes me quiver with happiness.
"Honey, it's not working out; I think we should make our relationship open-source."
This looks to me like they are changing a language so that existing apps no longer compile which is a bad idea. While I like many features of Java, I try hard to avoid authoring code in a language that has unstable syntax which results in a flux in the semantics. While it is O.K. to extend the language, the grammar has changed and many existing apps are not likely to compile without manual intervention (otherwise the compilers would be smart enough to figure it out). It is exactly this kind of "oh, we will revise the standard" years after the initial offering that hinders wide spread adoption, and opens the doors for the competitors (e.g. .NET).
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
I feel using programming shorthand leads to increased maintenance
:)
My code was hard to write to it should be hard to read.
the strongly typed language, that was good in 1996, now is weakly typed, now THAT's good in 2003, can anyone explain this to me?
Je t'aime Stéphanie
Hi,
FYI: Generics are _much_ more than mere syntactic sugar (as are enumerators, a weak form of algebraic datatypes, if handled type-correctly).
These are actually the kinds of things that make program maintenance considerably easier, since they allow more concise specifications of intended semantics to be done. No longer having to typecast (and thus expect run-time exceptions) when using a "vector of FooObjects" gives more power to the type checker, and thus allows a much richer class of programming errors to be detected at compile-time. This is the one major improvement in Java that's been missing since its very inception.
But note that "generics" or "parametric types" have been present in languages such as Eiffel or Sather for well over a decade, and for much longer in ML. In a way, it's embarrassing that such an essential feature was added this late during development.
Is anybody else irked by generics? One of the arguments in C++/Java discussion that I've read was: "Java removes complexity of C++, while remaining OOP". Well, generics remind me of C++ templates, which where a bit hard for me to swallow. Not to mention that attached to variable name doesn't make code any more attractive to look at.
It appears that Java's way to solve run time errors is to screw the bolts as tight a possible during compile time. Will generics become THE way, or just remain one of the options?
These new java features or shortcuts whatever reminds of C++... Is Java going to come with "Pointer" manipulation features later on? Will java become the next C++ and will be extremely tidious to program with? Overall, change is good... :)
buffering...
I feel the opposite. Enumeration types provide for strong type checking at compile time thus catching a lot of subtle bugs.
Generics worry me. Soon, someone will write something like ATL and we will have to have "Wizards" generating the code like for those poor COM programmers. As I understand it, Generics does not require a change to the byte code. The compiler just does checking and then provides the cast. In Java, all objects derive from Object and are allocated on the heap. Generics really doesn't provide the additional functionality that templates do in C++.
Java adds four new syntaxes, Python's for loop, Perl type checking at compile time, something called 'metadata', and C enumerations, all of which impove compile time type checking at the expense of making the source code look and feel like perl.
Because the compiler, unlike the programmer, never makes mistakes, the resulting code is also more likely to be free of bugs.
That's right, none of us has ever seen bad code generation or an internal compiler error. But, he does have a point. The compiler is less likely to make a mistake than a programmer.
I think the new additions are great (except, perhaps, the autoboxing stuff). But I'm missing a fix for that extremely common javabean convention: get/set methods.
/**
/**
/**
/**
To add a property, say a String called name you have to write:
* The name of this object.
*/
private String name;
* The name of this object.
*/
public String getName() {
return name;
}
* The name of this object.
*/
public void setName(String name) {
this.name = name;
}
That's 16 lines of code for one property! This is tedious to write, and more importantly, very hard to read when you have many properties.
This could easily be reduced to something like:
* The name of this object.
*/
property String name;
expanded to exactly the same code as above by the compiler. Incredibly useful if you're, say, writing a lot of value objects in a j2ee scenario.
#define FOREVER for(;;)
#define BEGIN {
#define END }
#define ONE 1
#define PUSHORT unsigned short *
#define DONE goto end
The first thing an amateur programmer does when assigned a new project in C/C++ is to go redefine the language and all the types. I scolded them for these kinds of things, knowing that once they were forced to read other people's code often that they would realize how stupid these kinds of things are. Unfortunately, once I started my career in embedded development, I quickly learned how stupid I must have been to think that people left these behaviors behind in college... (all the above examples are taken from "professional" code that I've seen in the last few weeks)
...just my 2 gil.
Don't suppose with this there will be a native FreeBSD port will there rather than having to patch and have 3GB have disk space free to compile it?
Rus
Cheap UK and US VPS
Check this out at IBM's developerWorks:w orks/java/library /j-emacs/
http://www-106.ibm.com/developer
1.4.x is rife with issues; corefiles or memory leaks (StringBuffer ToString anyone?). I sure hope that this is a stability improvement release rather than another round of 'improvements'.
Java is an OK language for teaching programming basics, but it's just too much bondage and discipline for my taste.
You're forced to do object oriented programming. OK, I can respect that - but Java is not consistent. Everything is not an object, and it's just so damned ugly when you have to wrap an int in an Integer.
Also, it's statically typed. It's so fucking annoying to have to typecast everything - I know I have a damn String - quit holding my fucking hand!
Furthermore, Java's text processing abilites suck so bad, I don't even know where to begin.
Give me Python any day. It can do any job Java can do, and probably better.
Please, please, tell me that there exists a company where the VP knows what a ClassCastException is!
It sounds like C# uses a lot of stuff from Ada (and I'm sure countless other languages), but forgot to honor prior work. :-)
Seriously, the "C# copied from Java/Java copied from C#" argument misses the point. There's a lot of prior work, and finding the right balance between usability and clutter is difficult. As much as I loved writing stuff like "for (value'range) do..." I would rather see a conservative approach to features since it's always easier to add stuff than remove it.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Some of this other stuff has been going on for ages - I'm curious about the metadata/declarative programming features. I've developed complete code generation systems for Java - the number of situations that require reams of very repetitive code in your average large-scale Java app is huge, and much of that can be automated. It would be great to see a consistent, standard system for doing this built in as a language feature rather than having hundreds of home-rolled systems everywhere, but the nature of many problems lends themselves to home-rolling. I can't tell you how many times I've written simple SAX parsers that spew out Java code, and rolled up an ant target to run it on some schema and package up the result. It's not clear from this brief example whether this is only for XML/RPC or whether there's an extensible metadata system that you can build on top of.
Then again, we should be careful not to roll too much into the language itself. I think generics, autoboxing, and enumerators are fabulous. Iterators I could give less of a shit over. Other stuff is great, but I question whether extending the language is the right mechanism. Much of the power and flexibility of Java comes from its simplicity. And most importantly, the ease of reading other people's code - there's far less stylistic variation because there are only N ways to do a task, rather than N! ways to do it, like in C++ (don't get me wrong, for a lot of tasks, I'd never dream of doing them in Java, like 3D programming). But it takes me about 1/4 to 1/3 the time to assimilate and learn a new Java API or library as it does to learn your average C++ API or library, and that's the appeal of Java.
Of course, I'll be thanking the gods that I never have to deal with the fugliness of casting and wrapping to move stuff between typed arrays and untyped Lists again.
They may be useful, but they need to avoid C++ing themselves with hard to read shortcut characters.
-
. . . are doomed to reinvent it.
foreach anyone?
null is zero?
That said, I've wanted Generics in Perl since the first week of using the language and I can't wait until they are available.
Disclaimer: I use Java professionally and Perl amateurly and I love them both.
While eclipse is great, Netbeans has more features. I prefer eclipse because it uses a native interface and has refactoring. The most feature-rich IDE I've used for Java, however, is netbeans. If you don't mind a slow user interface it's a great tool to look at.
Developers: We can use your help.
By Yours Truly (Shameless Plug): (And GPL/Artistic'd to boot) http://freshmeat.net/projects/gjal/
As a pro Java developer, I want to use the native 'int' type in order to save memory, have less garbage collection, and perform better. Catching errors at compile time is helpful too. I think it is unreasonable for Sun not to include specializations for native data types. If I want to have an ArrayList of 10,000 ints I should be able to use 'int'.
The link on this page states up to 10x performance but I've seen it work up to 30x performance - and you can run the code below to see this for yourself.
NOTE:
30 = 7272727/236966 where:
1. 7272727 = 2nd iteration of Int2IntHashMap!
2. 236966 = 15th iteration of HashMap (Hot spot had 12 more iterations to optimize)
http://fastutil.dsi.unimi.it/
package com.wss.utils.test;
import java.util.*;
import it.unimi.dsi.fastUtil.*;
public class TestFastUtil {
public static void main(String[] args) throws Exception {
int count = 400000;
int timerCount = 20;
long start, end;
Integer tmp;
HashMap hashMap = new HashMap(count);
for (int timer=0; timer timerCount; ++timer) {
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
hashMap.put(new Integer(i), new Integer(i));
}
end = System.currentTimeMillis();
System.out.println("HashMap put(Integer, Integer) count:" + count +
", put/s:" + (count / ((float)(end-start) / (float)1000)));
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
Integer in = new Integer(i);
tmp = (Integer)hashMap.get(in);
if (!tmp.equals(in))
throw new Exception("failed equals()");
}
end = System.currentTimeMillis();
System.out.println("HashMap get(Integer) count:" + count +
", get/s:" + (count / ((float)(end-start) / (float)1000)));
}
timerCount = 100;
Int2IntHashMap int2IntHM = new Int2IntHashMap(count);
int j;
for (int timer=0; timer timerCount; ++timer) {
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
int2IntHM.put(i, i);
}
end = System.currentTimeMillis();
System.out.println("Int2Int put(Integer, Integer) count:" + count +
", put/s:" + (count / ((float)(end-start) / (float)1000)));
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
j = int2IntHM.get(i);
if (i != j)
throw new Exception("Int2Int failed equals()");
}
end = System.currentTimeMillis();
System.out.println("Int2Int get(Integer) count:" + count +
", get/s:" + (count / ((float)(end-start) / (float)1000)));
}
}
}
Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ (Java Web Startable)
Why can't this new release of Java include selective compilation?! It's incredibly useful in C/C++ to implement common functionality with different platforms and stuff. Yeah, yeah, I should be using inheritance/interfaces/abstract classes to be doing this in Java, but why should the compiled bytecode be bloated with stuff that doesn't need to be compiled in?
this is beginning to look like clean Qt/C++ code...
Especially the iterators, etc.
Are Sun "inventing" an "interpreted" C++ ?
Trolling using another account since 2005.
In both cases, they came late to the language, so they're a bolt-on, not a designed-in feature. C++ before generics was awful. Remember those schemes for generating classes using big preprocessor macros? Unchecked downcasting? Strostrup had a big blind spot there. C++ is still less type-safe than it should be.
It's a bit wierd for Java to get generics. One of the claimed features of Java was that you didn't need them. Java is supposed to be "polymorphic". But it's too early to judge.
This isn't the forum for a detailed discussion, but I actually prefer enumeration classes now over simple enumerations. The basic idea is to write a class something like:
final class Color {
String c;
private Color (String color) { c = color; }
String toString() { return c; }
static final Color RED = new Color("red");
static final Color BLUE = new Color("blue");
static final Color GREEN = new Color("green");
}
You can then treat this class like a type-safe enumeration. It doesn't have all of the nifty features that you'll see in languages like Ada, but it has the nice property of allowing you to attach whatever information you want to the enumeration class.
You can also use this approach to create self-initializing classes, e.g., a list of states (including full name, postal abbreviations, shipping zone, etc.) from a database. You can access the enumerated values through a collection class, a "lookup" method, or even reflection.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
One of the coolest new features of JDK 1.5 is the completely reworked concurrency stuff (JSR 166). I just listened to Doug Lea (spec lead) give a talk on this very subject and I'm pretty convince this will rocket Java performance way up for a lot of the collections stuff, concurrent programming, etc.
/ oswego/cs/ dl/util/concurrent/intro.html
:)
Bascially, the goal of JSR 166 is to do for concurrency programming what JDK 1.2 did for data structurs (Collections stuff). The gist is, you'll never need to use "new Thread()" or "synchronized" anymore, but rather you'll execute Runnables, use Locks and Semaphores, etc. Also, queues are *completely* reworked to be ultra scalable.
JSR 166 is based on Doug's concurrency package:
http://gee.cs.oswego.edu/dl/classes/EDU
OH, and there will be classes like AtomicLong which guarantee atomic 'compare and set' options for primitives.
Cheers!
Interested in Generics?
A Compiler for generic Java has been available for years:
You can check out Pizza/GJ here or here
I think "true" properties are a big mistake for a language. I'd much rather have the explicit "get" in front of the property's name to make it a method than the possible ambiguity of using only the property name to mean two things. Also I think the way of writing properties in C# is very ugly. But at the same time I couldn't think of a much better way to do it. All together I'd rather have functions.
Developers: We can use your help.
> But note that "generics" or "parametric types Generics are much more than typed containers, I'll have to read more on the Java implementation. The most useful part of generics is of course generic algorithms. Hopefully java generics are more than the hijacked "Design Patterns" they gave us with JavaBeans - a Java "Design Pattern" is to name a getter as "get" and a setter as "set".
are answered here. it's lies by microsoft vs lies by sun to make $$$
Generics
The new Java generics are really weak compared to C++ template support. This is probably partially due to difficult in compiler support and also complexity (templates are without a doubt the most complex feature of C++). I was disappointed though in Java generics mainly due to lack of any kind of specialization support and also about the strange paradigm used for Iterators (instead of an iterator being class defined with a consistant interface, it's an external class that just behaves that must wrap a behavior around the class).
Enhanced for loop
This is for_each() in C++. Now, with for_each, you have to use function objects which is arguable as to whether it's more readable. Fortunately, Boost has developed a boost::lambda class that allows for code to be used as the third parameter. This is _really_ neat.
Autoboxing/unboxing
I presume this means that primatives can't be used in generics.. That's kind of sad. This isn't a problem in C++.
Typesafe enums
This would be a nice linguistic pattern to have in C++. As it stands, the equivalent would be:
struct Coin { enum { penny, nickel, dime, quarter }; };
Static import
This can be achieved via using in C++. Of course, Java doesn't even really have a namespace paradigm so it's not really a fair comparision.
Metadata
This is.. well.. strange. I didn't see the syntax for doing something like this. If it is just keyword/code replacing, then an #include directive would work just as well.
int func(int a);
func((b += 3, b));
AC, I agree that the current approach is a PITA. I would also be very happy to see a more terse way to express properties. But what you are doing in your example, is throwing the baby out w/ the bathwater.
Note that you now don't have anyway to specify access and protection! I had given a little thought to better ways to handle this, and even had an interesting brief email exchange w/ a C# engineer about it. For the protection aspects you could do something like [this is just a quick idea I cam up with:]
property access String name;
where access is one of {read, write, readwrite}
But note taht right away you have a problem -- no way to assign protection levels to the various access, which is really a cross-product. What happens for example if you want the getter to be public, but the setter to be private?
Also, note that you would also need semantics to handle overriding the property accessors. You could just say that the property access defines an equivalent to the getter and setter methods, but that can get weird and confusing very quickly. Think about the situation where you have an interface defining getters and setters and then you implement it by just providing the one-line property definition. That would not be very transperent TSTL.
All this is just to say that it is a noble goal, but not as trivial as it sounds at first glance. IMO, the C# "solution" is particularly ugly, and qualifies strongly for the "syntactic sugar" label.
FInally, as in my other note, good IDEs like IntelliJ provide very convenient ways to auto-generate these things. I care much less about this issue now that I am not having to type all this stuff out by hand!
If I understand the article correctly, this would be possible using the new metadata features, so then a "tool" could generate the getters & setters.
;)
That said, having it built into the language directly, so you didn't have to rely on a "tool" to generate them would be certainly be more convenient. Maybe they're holding back features so they have something for the 2.0 version of the language...
I think a number of the 'improvements' for 1.5 are nothing more than syntaxic sugar that are pushing Java in a bad direction. One or two these enhancements does offer some lesser compile time checking which is a good thing, but for the most part they seem to be an attempt to let the programmer type fewer characters and letting the compiler 'generate' the code.
Why is that bad you might ask? I mean who wouldn't want to do more in fewer keystrokes. Well there are a few major problems that I see:
1. There is a much greater ability to get into the "Perl factor" where there are 16 million ways to do the same thing. While having so many ways to get the same thing done is great if you are one or two folks working on a project, its terrible if you are 20-30 developers working on the same project. So these 'improvements' seem to push Java away from being a good Enterprise level language.
2. While none of the changes specifically target this, its movement away from being a systems language where the programmer is very close to the underlying action that the computer is doing. One of Javas greatest strengths is its ability to get deep into the bits (like C), and while this is not going away this seems to be where alot of the thinking is.
3. These 'improvements' will be all that some newer programmers learn. I think this will lead to a much greater number of java programmers who don't really understand whats going on and we will have a lot of confusion out there.
All of this because some people wanted to save a few keystrokes.
JDK 1.5 is coming out soon, and I still haven't really gotten to play enough with the new stuff in 1.4!
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
Unlike some people, I feel using programming shorthand leads to increased maintenance.
AMEN! Look what shortcuts do to PERL!
Java is normally very readable, even by people who are not familiar with the details.
I can't think of any gains afforded by shorthand syntaxes, projects are not usually billed in keystrokes.
I do like iterators if they mean less nested for(...) loops, but you can't always convince people to use them.
I would *love* to see operator overloading. It would actually make Java much more useful for scientific tasks which involve things like vectors, matricies, or complex numbers. I'm also sure it would also be helpful in other areas.
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
- It offers features I can not find in Eclipse
- it's more mature
- it's easily extendable. (some parts of the development cycle of the company I work for are already implemented as netbeans-extensions)
some downsides are:- you have to get used to it.
- it uses Swing instead of SWT. (with execution and startup speed really improving in the last releases.)
and it's open source...while (!asleep()) sheep++
When it comes down to it, once the code is compiled, it's the same.
If you're compiling, shouldn't you use a language which wasn't designed to be interpreted?
Generics aside, most of 1.5 are interesting ideas that have value, but they should probably NOT be built into the language.
If you consider that most of the features in 1.5 are essentially macros to generate code, it seems like Sun is trying to bind IDE features into the JDK itself. This strikes me as a BAD idea for a language, and should be somewhat personnal choice (e.g. let each programmer make they're own macros instead of tying them to the language).
Well having to use java day in day out and mostly loving it, here is a personal comment.
The generics and the autoboxing are heaven sent from a language standpoint. The other stuff mostly is syntatic sugar and the static imports I really don't know if that is a good extension to keep the code readable. But the biggest gripes with java are not the language but two other things:
a) long loading times caused by the class loader class verifier mechanism
b) huge memory footprint thanks to mem hungry hotspot optimizations
What I really couldn't find is if those two issues will be adressed or postponed again.
Btw. if you like java but think that swing is slow in X check out the latest blackdown release, it is amazing what the blackdown guys did to swing. Also check out the 1.4 JDK for the mac, no difference to a native mac app speedwise.
OK, Java is shit, but Java is where the money is. If you choose not to work with Java, it limits your career.
This is totally fine with me though. More money for me!
oh, fuck france.
This is what he said about Java and the likes.
Also here.
Now how much would you expect to pay for templates, enum and bizarre @ keywords? With the new Java 1.5, you can have all this for three easy payments of $19.95!
Anyone else think that the article read like a Saturday morning info-mercial?
Don't you mean /.?
There are some good points that have been deleted by the moderators.
All the messages about java being about profit for sun have been DELETED(not using modded down term) .
All the messages about java language being too wordy,slow, or even people griping about certain syntax of the language has been deleted.
Take the FILTERS off for all JAVA news submittions.
I am guessing here that the MODERators are JAVA programmers.
You do not need to mod down a submitted message to Troll if it has actual substance to it.
pathetic.
This is one of the nicer things about C#. How often in Java do we see code such as:
// Do some stuff...
// Never been sure what to put here...
// just logging?
// Do stuff
BufferedReader br = null;
try
{
br = new BufferedReader (...);
}
finally
{
if (br != null)
{
try
{
br.close();
}
catch (IOException e)
{
}
}
}
The equivalent of this in C# is:
using (BufferedStream bs = new BufferedStream (...))
{
}
Basically it's the same thing (can't remember what happens to exceptions during Dispose, admittedly).
Much easier to get right. Means having a common interface for "I've finished with this object", but that's not too hard...
I'm hoping to put together a proper RFE for this at some stage.
I know I just ate a big pile of PR, but these changes seem good from a developer's perspective. Once 1.5 goes final, I'll probably re-compile using some of these new features.
Get Firefox!
Yes, Generics can be used for much more than this, particularly in combination with anonymous classes (which are Java's way for handling higher-order functions). Again, a lot of examples for this can be found in existing languages, e.g. we can now have something equivalent to the 'map' function found in functional languages. Here's a Haskell definition of map:
I don't know the precise Java syntax for Generics, so I'll make one up for a Java equivalent:
Granted, it's not quite the same, particularly since it supposedly works on all containers (with the right kind of iterators) and performs a destructive update, but you get the idea-- you can do powerful stuff and still get your types right.
-- Christoph
Does it import all static members and static methods or just constants (static final's)?
x++ is the standard way of writing the statement, used by most coders in preference to ++x (in my experience anyway.) The fact that there is such a convention is reason enough to use it IMHO; if I see ++x in a piece of code, it's a warning that something unusual is going on.
As for your equality test examples, putting assignments in if statements in Java gives you a compile error. Also, it's quite rare to ever put a specific number in an if statement, and if you do it's likeley to be 0.
One of things that makes older more mature languages like Common Lisp (and perhaps Smalltalk) nice to work with is a feeling of both having really solid implementations and not breaking legacy code.
I like the idea of boxing and generics, but, these changes will affect old code (probably?) and the platform in general.
My vote would be to freeze the Java language (perhaps after 1.5) and concentrate on the following:
I would not like to see Java become a language designer's playground.
Because of great infrastructure software like servelt/JSP containers, (perhaps EJBs :-), XML utilities, solid web services support, etc. Java is a great platform.
Leave it alone (the sooner the better) except for improvements in the implementation.
-Mark
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
sun has been rumored as a target for acquisition. what if microsoft buys sun? what would become of java?
what if ibm buys sun? java would thrive, but i do have some concerns. when connecting a java client to a websphere ejb, the client jvm must be the same version (from ibm) as the webpshere jvm (from ibm).
just some ramblings...
andrew
Why did I lurk so long before registering for a Slashdot account? I could have had a Slashdot ID of less than 100000.
I've been using Java for most of my projects for years because it didn't let you get away with many of the confusing things that you can do with a preprocessor. I may sound like a big geek for this, but I was actually weeping while I read the article. JDK 1.4 broke the ice with the assert keyword and now everything bad about C++ is going to pollute Java.
To the many cooks who spoiled the broth: "Thanks a lot, assholes."
When C# came out, all the features you're singing praises today to were called "syntactic sugar" by this very community. Now they come out in Java and it turns out it's such a huge innovation that nobody can live without it. Next thing you know you'll be praising true properties and delegates. :0)
Java is still strongly typed, but weak typing is good now in large part because of test driven development. Unit tests that you design yourself and run as part of the build process enforce your constraints much more effectively than strong typing does.
For more, read Tim Bray's piece on this.
Four fifths of all our troubles in this life would disappear if we would just sit down and keep still. -C. Coolidge
it's all a con. It's about sun $$$. And nothing great about it anyways.
This is great, with generics and so forth, Java is beginnig to be a REALLY sweet language! From the looks of it, Java 1.6 will be called "C++" :)
... but man do I hate the enhanced for-loop syntax. At some point you have to give up perfect backwards-compatibility for readability. One or two new keywords would do a world of good.
for (TimerTask task : c)
task.cancel();
becomes
foreach (TimerTask task in c)
task.cancel();
All computer languages undergoing rapid user-driven evolution are doomed to either converge on perl or python. Looks like java is heading pythonwards.
Oh, totally agree. I was assuming a single line, or in a for statement for example. In that context it is the best way, but in another..
Is this really the number one problem for most projects? ClassCastExceptions in production code?
Thanks a lot Sun for posting absolutely no information about the progress of this JSR. At least Doug Lea has posted a little information.
Anyone?
Jesus fucking Christ.
If you want a lightweight IDE, look at JCreator. There is a free version here!
What, me Tweet?
They are ugly and of little use. Java has a different object model than C++ so Generics are not as useful as in C++. They do provide for compile time checking when adding objects to a collection class. However, I use collection classes extensively and have NEVER put the wrong kind of object in one. Even if I had, it would be caught by the run time checking the first time I tested the program.
pre-increment is usually slightly faster than post increment. I can't rememenber the details, I'm sorry, but it's something about not making an internal copy of the variable be incrementing. This can be material if you're trying to get every bit of performance out of a piece of code.
Which raises the point. I've noticed that quite a bit of "equal choices" in programming aren't really equivalent. There are cases where a "for" or a "while" loop can be used, but really one choice is much, much better in terms of performance. But the result is the same.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
i agree with both of you. read this article.
Generics were not in the first release.
The language continued to change for well over a decade before being standardized by ANSI.
If Java had been done "right", it would not have been done at all.
@HbFyo0$k8 tH!$
I am not convinced about generics. Generics with a test bed being C++ created nothing but nightmares.
Before generics it was possible to take a C++ program and integrate it with another C++ library without much hassle. Sort of like how it is with C these days. Integration is not that difficult.
Java integration is an absolute piece of cake. There are no issues whatsoever. But I fear generics is going to complicate this situation immensly.
What I get concerned about templates is not the List type templates. Those are ok. Actually pretty nice solution. What concerns me is when we start the following List > > >. This is where C++ integration falls flat on its face. And I fear the same will happen to Java.
Additionally what I always liked about Java is that it was simple to get things done. Generics adds a complication that most programmers do have problems with.
Having said all that I am curious to see how it all plays out. But there is one BS statement:
Without generics, you discover such a bug when your most important customer calls your VP to tell him that the program on which his business depends just crashed with a ClassCastException.
Yeah right and these "crash the business" bugs will disappear? Oh yeah, and let me show you my porfolio of land in Florida!
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
Do you like seeing "public void setX()...public int getX().." a hundred thousand times to implicitly declare a bound property? Or would you rather see "published int x;" (to steal a line from C#) and be able to refer to x by field name rather than accessor method? I think simplifying code like this is a good idea. However, there is a dilemma created herein, as the example below will illustrate!
Thought Experiment #1
Assumption: Maintenance cost is directly correlated with program size.
Therefore: The more terse the language grammar, the easier programs written in the language are to maintain.
Thus: Perl.
At that moment, the programmer was enlightened.
I added a whole bunch of brackets and the browser is cutting them out....
Here is where I get concerned with brackets
List[ Container[ Container[ String, Object[Long] ] ] ]
That is complicated
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
> Unlike some people, I feel using programming
> shorthand leads to increased maintenance.
How does changing from int to enum increase maintenance? Either way, you've got to look up the values in the class where they're defined.
I've learned shorthand can be nice if used in a sane manner. C/C++ macros can be utilized for saving a lot of typing. The C/C++ goto construct can be a really nice way to clean up within a function/method call. I find shorter/cleaner code to be easier to maintain.
I'm not sure how locks and semaphores are a step forward from monitors, which is what "synchronized" represents.
Are you claiming "synchronized" is inefficient? Did you see the developerWorks article?
Are you claiming that such a high-level structure as a monitor is unnecesary for real programmers, who know what they're doing and will never screw up using synchronization primitives?
John.
" I feel using programming shorthand leads to increased maintenance."
False.
Shorter code and more powerful idioms makes a program *easier* to debug.
Too much code makes the purpose lost in the noise. Consider:
foreach (@array) {foo $_};
and
my $i;
for ($i = 0; $i < $#array; $i++)
{
foo $array[$i];
}
(I use Perl here since it is well known and I can show the 2 idioms, but really Perl isn't the clearest language of all). One form is much clearer and reveal much more eloquently what is the intent of the code.
Of course, this doesn't mean that shorter code "at all cost" is easier to debug, it means that "less code" is better.
Oh, and also it pisses me off when management tells me I need to use only certains idioms in case someone comes over my code and don't understand it. I hate to have to program like the next maintainer will be clueless and ignorant.
cheers
My code was hard to write to it should be hard to read. :)
"Real Programmers don't need comments-- the code is obvious."
-- Real Programmers Don't Use Pascal
The net will not be what we demand, but what we make it. Build it well.
It's interesting the problem they were having with unboxing. Right now a null pointer would return a int value of zero, rather then throwing an error.
Actually, I think that's a bad idea, since you wouldn't be able to tell a zero you put in a collection with one that you didn't. Personally I'd like to see this as an option, somewhere. perhaps as a parameter to Integer, so you could do Integer<0> or Integer<null> to chose the behavior of the class. The problem there is that it's not obvious what a parameter to integer would do. Although I suppose you could use an if statement.
Personally, I wished they would have thought up a more interesting way to do generics then the C++ model. I wonder if this is going to give us the full range and power of C++ templates in java.
autopr0n is like, down and stuff.
....that C++ is perfect and using other languages is useless. .asm have always been easier for me to grasp I guess....no hiding things, what you put in is what you get out. Smalltalk is cute though. :)
C++ does it all, does it faster and although may be harder to learn, allows the programmer to make the choices. I've always beleived that if learning a high leval language like C++ is too complicated for you, you have no business working on anything even remoatly serious. I have always felt like I am being held back with most other languages, including Java, but with C++ I have felt like I can do anything. I have choice over pointers, generics, classes, friend fuctions....I guess I love the fact C++ allows you to break all the rules...which can lead to clever tricks....it's beautiful. Lower leval languages, as well as
Why was the for operator enhanced instead of introducing a new keyword (such as "foreach") which would lessen the confusion, build on the understanding that most programmers who've seen other languages have, and make much more sense in general?
"Generics"? Castrated templates.
... Whenever I see this corporate programming designspeak crap I thank God that Apache wasn't written in Java.
Enhanced "for" loop? Syntactic sugar. Oh and for God's sake, don't use new keywords. It'll be destabilizing.
The "split type system" in Java has always compromised Java's status as a true OOP platform. Seriously, this is supposed to be exciting? Java is how many years old and they've finally made it oh-so-easier to convert between primitive and class types? Aren't there enough conversions in a strongly typed language?
Typesafe Enum pattern, Constant Interface antipattern
Metadata programming. Now Java will have code that emits code before the compiler emits code. Well, there goes Java having no pre-processor. But in true Java fashion, it looks like this "framework" will be much, much harder to use than a pre-processor, so that's good.
Bottom line, Java is Byzantine, slow, bloated, and now playing catch-up. Want to avoid all this verbose, camel-cased code? Go C++. Yes, you'll have to learn how to write secure code, and yes, you'll have to use pointers, which are supposedly EXTREMELY DANGEROUS, and yes you'll have to learn about how your computer works a little more to be an expert. Of course, Java requires none of these things.
If you must go with some absolutely proprietary platform, then go C#. At least it's standardized. Oh, oh, Sun was going to do that with Java but then, you know, didn't.
Chr0m0Dr0m!C
I write code.
ML (at least) has parametric types, but not generics.
I often also enhance myself with sugar.
You know, I've just got to say this.
Each and every point on this list of additions to the languages addresses problems that I have personally run into in my use of Java at work. These things will make the writing and maintenance of java projects small and large much, much easier.
Generics: Thank you God, yes! Having to explicitly cast objects out of Containers is tedious and error-prone.
Iterators/Enhanced 'for': Make iteration much easier to read and understand.
Autoboxing/Unboxing: This helps alleviate the enormous kludge that is the Object/primitive dichotomy. Casting to and from wrapper types just to pass ints, etc. around really sucks.
static import: Not having to fully specify tedious class names to access static members is a big boon for making stuff digestible and easy to read.
Metadata: Writing boilerplate sucks the big one. How many hours have I lost writing boilerplate? Way too many. Having language support for generating code from the metadata cuts my implementation times way down.
I could sit here and argue with folks about the 'new Java' versus C++ or C# or Smalltalk or whatever endlessly. But man, these things sure make Java a whole lot more pleasant to use.
-- Flaw
That Java is lacking a few things I'd expect from such a popular language.
Now, I'm not the most experienced programmer in the world, but I've found that unlike other languages (especially C++), lots of different common tasks don't have standard methods for doing things. This suprises me primarily because the JDK is chock full of built-in-abstact-data-type goodness (I'll never write another Linked List again =D ).
In C++, where you have cin, with Java, there are a number of different setups that produce the same behavior. However, most of these seem non-trivial when compared to the simplicity that libaries like C++'s iostream provide.
So I feel adding common shorthand tasks is a good thing. If you know what you're doing with things like enumerators, you aren't going to cause much damage.
Vonal Declosion
bought my macromedia, and shitcanned. it was a good ide for windows. eclipse is great, but a litle heavy. for overall use, try jedit
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
The name "ratboy" stems from a contest. We were having a patio party whose theme was "worst songs of the 70s and 80s". Each had to get up to sing. My contribution (almost the winner) was "Ben". Since then, I have been known as ratboy.
Ratboy.
PS. And I stick by my original source... and I really wish I had a friend like Ben.
Just another "Cubible(sic) Joe" 2 17 3061
The URL just had a space in it. Just try it as an actual link:
http://www-106.ibm.com/developerworks/java/library /j-emacs/
(For some reason, /. seems to want to stick that space in there, but not on the actual hyperlink)
I was a text editor/command line person until I encountered Eclipse 2 and I've never looked back since. http://www.eclipse.org/
Only (small) drawback is that the UI is just a tad sluggish. But if you have a 1GHz+ machine you're unlikely to notice.
And if you are a webapp developer the Tomcat plugin really makes life easy.
This method :
void cancelAll(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
TimerTask tt = (TimerTask) i.next();
tt.cancel();
}
}
can be replaced with
void cancelAll(Collection c) {
for (Object o : c)
((TimerTask)o).close();
}
using the enhanced for statement. So cancel() changes to close()?
One thing I remember about win32 programming back in the day, was the insanely nested if statements (for example, in example programs) You had like all these blocks of code like
if(doOneThing(lpfSomething){ if(doAnotherThing(lpfSomething){ if....
And so on, it was just a huge amount of wasted code, and if you added error handling for each condition made it huge.
Exceptions are so much nicer...
autopr0n is like, down and stuff.
It makes me really sad to read this. Java is a long way behind the state of the art for expressive power. These changes are welcome but Sun are presenting them as though they are innovative. Three lines to remove the four character strings from a collection? Look at it in Python:
/= 4) list
filter (lambda x: len(x) != 4, list)
If you object that Java is doing type checking, and Python isn't, look at it in Haskell:
filter (\x -> (length x)
Time to move on I think...
Generics should have come much sooner.
// username(String) => UserRecord
:(
Today, without the language support, I ask every programmer to minimally add a comment to document the data type used in the collection, like
HashMap myTable;
Still many people fail to do just that. I have to trace the typecast and the usage of the collection to discover what are they putting in the collection.
The proposal seems to keep Java collection's light -weight design. It simply provides some compile time checking and implicit typecasting. It avoids the complexity of C++'s template. I remember I have spent a lot time debugging the compilation. An error message would spend multiple lines with long and unreadable class names decompose of a template instances...
For the gaping holes and pitfalls he has created in C++. Everyone who has read books from Effective C++ and Exceptional C++ series knows this. In Java or C# you've got to try to shoot yourself in the foot, in C++ this comes by default, you don't even have to do anything. Some insanely simple situations shoot you in the foot so bad, it's not even funny. Not that C++ doesn't have its uses, but its usage should be limited and punished for. Thanks to Bjarne's "excellent" design, devs punish themselves every time they use the language for something non-trivial.
my favorite language (extension) for the vm has always been pizza. It gives you said generics, but also
- first-class functions and
- algebraic types (think functional pattern matching)
all three compatible with the original jvm 1.0 specification.But to be honest: this seems to be a real great step for java. programmer with a certain need for aesthetics (and self regard) can now really use this language...
"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." --Alan Kay :)
I don't mind C++ (or Java) that much but spend enough time on the Squeak ML and you get an idea just how much the other OO languages have been playing "catch-up" to Smalltalk, from a power standpoint.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Visual J++ is a great way to make Java programs
Don't get me wrong, I wouldn't do win32 programming unless I had no food to eat. And even then... my food wouldn't taste as good.
But...
Exception Handling doesn't get rid of logic statements, it just does for exceptions. And these come at the expense of a lot of overhead.
I agree Exception Handling in java is nice, but this is all done by Objects. Objects are removing the spaghetti code. But it is VERY nice that java has them all done for you. And you can use objects when coding for win32, even if you would have to write some of your own.
Plus, to be fair, coding an XWindow program is no joy.
Oscar
A program should express WHAT you are doing, rather than require you to faff about detailing HOW you want it done, unless you actually want to.
A programming language should make this easy with syntactic sugar.
Humans read programs.
Computers read machinecode binaries.
They need to include an option to not include bounds checking in arrays. Right now Java is becoming very popular in physics because it's easy to use and portable across systems. I know a lot of people in physics who program in Java and I've worked the past two summers as a summer student writing code for physicists. The biggest complaint both they and I have in the bounds checking it does. It's a great option for debugging, testing, and for running most applications. But when you are running a large program the overhead of bounds checks in arrays can be prohibative. Ideally I would like either a runtime or compiler option where you can specify to run it without bounds checks. Obviously this wouldn't be a good idea for a great many apps but it would be extremely useful when running an array heavy application that takes hours or days to complete.
I stole this Sig
nearly approaching the homosexuality or you and your post.
-1 Offtopic
Sounds to me like they just slurped in XDoclet, just like they slurped in Log4J in the 1.4 release.
This is exactly what the new Java enums do. You just get to type a lot less and you can use them in case statements.
autopr0n is like, down and stuff.
One of the examples discussed in the article compares the following pre-generics code to the generic code:
/* Remove the four-letter words from the specified
* collection, which must contain only strings.
*/
static void expurgate(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
String s = (String) i.next();
if(s.length() == 4)
i.remove();
}
}
Here's how the same method looks with generics:
static void expurgate(Collection<String> c) {
for (Iterator<String> i = c.iterator(); i.hasNext(); )
if (i.next().length() == 4)
i.remove();
}
Here's the same method written in Python:
def expurgate(col):
return [ s for s in col if len(s) != 4 ]
Now tell me, which of the three is the most consise and readable expression of the idea?
Arguably the most terrifying sig I've ever seen.
Let me add that people are being forced to use this language like slaves.
Academia and corporations are slaves to propoganda by sun.
In the old days when people talked about Linux, there was an expression "What about the big pink elephant in the middle of room" and it was referencing the fact that Linux did not support truetype fonts and font aliasing. Now some of that has been fixed, but Java still has its big pink elephant. Here are some of the things that people don't talk about.
The memory foot print for loading Java is 20meg + and growing. I am part of a team that has been developing a complex Java application for the last few years and we have created about a 3meg library (and it probably does at least as much as the more popularily used Java classes). I have looked at some of the source code for the core Java libraries and it is clear that a good rewrite could reduce this footprint by a factor of 2 to 4. Currently, C# loads with a footprint of 2 meg to 4 meg. Most other scripting languages usually have engines that are about the same size. To put it simply, the base core Java libaries are unjustifiably large. Maybe if Java were truly open source this could be addressed, but of course Sun doesn't even believe in submitting Java to a standards board.
You cannot load the Java VM once and run multiple processes (note "processes", not "threads") from the same Java VM memory footprint. I hear that such a thing is becoming possible for C# on Linux. You would have to build all the core Java classes into a "DLL" or ("so" on Linux), but that shouldn't be so difficult.
You still cannot do basic OS operations in Java without writing your own JNI library. The one that stands out is the inability to get the ID for the current running process. The "nio" package has corrected some of these issues, but the "nio" package should be the "io" package instead of having two separate packages (similar to AWT vs. Swing).
Window focus handling is still terrible. Ever have two frame windows up, have a modal dialog pop up on one frame while you were looking at the other? The frame window without the popop modal dialog becomes unresponsive and the other frame cannot be reached by tabbing through the windows. Only if you are lucky and that window is still visible on your desktop can you successfully reach it. Also, if a user clicks on a button that generates a modal dialog, the frame is only locked out from user input once the dialog manifests. This creates the infamous "double" clicking problem.
Java's package management is still primitive. If you want to do anything more subtle then using the classpath to load in custom libraries, you have to write your own class loader. Having an auxillary file specifying parameterizable rules for class loading would be nice. It would also be nice if you could ask a running Java process what packages it had loaded (and metadata about them such as location and version). Compare this to C# (or the way some of the web server oriented scripting languages work).
Some of the basic core library functions have some major weaknesses. For example, the Hashtable should be written as a native object when using String lookup keys and also allow you to dictate the algorithm for creating hashes (ex: use first 8 characters, last 8, or middle 8). There should also be a non thread safe version as well as a thread safe version. The lack of such a natively implemented primitive object is one of the big reasons why some less cleverly implemented scripting languages (such as python) can beat Java in performance on many web applications. In general, the core collection classes should be implemented in pure optimized (down to the actual chosen assembly code) native code.
Many of the utility libraries are broken in fundamental ways. Send back a badly formed response to the HTTP library and you go into an infinite loop when it falls into its keep-alive/retry logic. Date parsing is still behind what is available in the C standard library. Locale specifications do not allow you to independently specify date formats, language, floating point format, currency format, and time zone. You get o
When will Java support shared jar files that work like shared objects or DLLs in operation systems?
IMHO this is one the main shortcommings of Java. Every jar file is loaded into every process causing a huge memory footprint and long startup times.
When playing around with some java shells, that only load classes once and simulate processes as threads, I saw simple swing applications load in 0.1 secs and other significant speed ups.
I was hoping for it in 1.4.x and now it seems it won't even make it into 1.5. I realize that it will be hard to implement this in a platform transparent way.
Sun wants control of servers for their own profit. It's that simple. Why can't anyone see this?
Collection c; ...
for (String s : c)
What if I have a data structure that is logically iterable yet not a Collection nor an array? How would I use for in say, a Vector or Matrix class of my own design? What if I wanted that for loop to iterate over the elements of a Matrix in some nonstandard denumerable manner?
It would seem more logical to me for Java to simply apply allow blocks as used in Smalltalk.
URL : Enhanced for discussion on JCP site
URL : About Smalltalk Blocks
What language feature isn't syntactic sugar? High level computer languages are all shorthands for machine language. It's all about making it easier to read and write. It's bizarre to criticize Jdk1.5 for adding one ounce of sugar to what's already a ton of sugar. These are all features that I thought were absurdly verbose when I first learned Java, so I'm pleased to see the changes.
The example above simply does not reflect the fact of controlled access, and one can make it more "convenient" by rewriting as:
ha!haha!
seriously. That's the funniest comment I've seen on this. A VP who knows what a ClassCastException is! Haahahahha! That's RICH!!
hahaha!
Dam. I can not imagine work without them.
I suppose I could work without them but I disagree with the story that it would make difficult code to read.
If I am writing a turtle graphics program for my cs101 class which is easier to read....
write = penup;
direction = verticalup;
or
write = 0;
direction = 0;
The first is obviously clearer. The second would confuse the person debugging it because he/she would have no idea what 0 represents.
I am planning to learn java after c++ is done and I could not wait for the cleaner language. However I am shocked that enumerators were not in. Pointers are a dual edged sword and can be nasty stuff so I see why sun got rid of them.
I use pointers where they are appropriate but I only use them when appropriate. They can be quite dangerous.
http://saveie6.com/
Unfortunately, this doesn't quite make Java competitive with C# yet. Major missing features are:
Also, Sun's patents on core Java technologies and the lack of a well-defined, open Java standard are still serious problems. The fact that Swing is de-facto part of the Java standard but that Swing is as ill-defined as the Windows API is another problem because it makes it hard to create open source implementations of Java.
An other awful consequence of operator overloading is that code like thisis unsafe, since the && may be overloaded.
(The above may not be valid C++ syntax. I left C++ for Java many years ago and I'm never going back!)
But it is true that its possible to build syntactic shortcuts that do unexpected things. I think that operator overloading has the potential to do this in C++ - not so much because of the kind of example given as because of some of C++'s added, um, features.
In particular reference parameters tend to give me problems (but I should say up front that I'm nowhere near smart enough to use C++). The fact that "x=y+z" might do odd conversions (such as given in the parent article) is annoying enough, but the fact that because of operator overloading and reference parameters all of x, y, z might get changed and in odd ways, just makes me cringe.
Of course, there are good reasons why someone might want to do that - or at least there is a someone out there who will think that the reasons are good. But its all too much for me.
I haven't looked carefully into the boxing/unboxing mechanisms described so I don't know if they might be abused in similar ways. (Crossing fingers for luck.)
Sather iterators had it right - incredibly powerful and able to leap tall buildings in a single bounds-check.
I'll bet that use of Sather iterators reduced my code size by half.
Someday someone will reinvent them, graft them poorly on to some other language and people will find out what they've been missing. Sigh.
But then Sather also had a great program-by-contract feature, very very nice support for generics and FABU!(tm) support for operator overloading in a way that I could understand.
You're a perl programmer, aren't you?
Are you sure you don't want to recursively map f onto the tail of your list?
I'd rather be lucky than good.
I always get the creeps when I see if( xxx ).
It is as if "if" is a function putting the parentheses like that.
foo( xxx ) is a function call
if ( xxx ) is a statement which gets a block in parentheses.
I couldn't resist. I have to fight this good fight every day against some of my colleages.
I hope this isnt yet another broken jdk....jdk 1.3.1 wasnt the best thing in the world..it was pretty slow..the implementations sucked....but there was no Real broken stuff in it.
.so files in their proper places....and literllay hundreds of other errors i have stubmeled across.
JDK 1.4.x is very broken...for example...if you make more than 10,000 rand calls...you will actually push the main thread out of sync with the garbage collection thread...and alot of your variables will dissapear. I've actually had this problem...and the problem of the VM just outright seg-ving on me all the time.
Also, list iterators are broken with the checkConcurencey method of iterator, parts of the JDK 1.4.x wont even compile...even with all the
This has lead me to have to completley re-implement anything from the jdk on my own in production code. Its just to unstable for me to use it in anything that goes into production. Not to mention its as slow as dog shit...and if you eve read the implementation of the jdk....your left going What the fuck? the implementations are very poor in desgin and code...its no wonder they fail.
Hopefully they will fix this in jdk 1.5..at least bring themselves back to were they were with jdk 1.3...i have to say after working with jdk 1.4.1 and several of the betas.....you really start to understand were the concept of Euogenitcs comes from.
All of this has lead be to use the Blackdown JVM..and JDK...they actually work...still quite slow...but double the speed of sun's VM...and the JDK dosnt break. Howeever, since there is no windows version of Blackdown VM, it really can mainstream...so were left with Sun's pice of shit. Hopefully, with JDK 1.5, I can at least use a JDK that will at least work.
Because if an exception is thrown, you still want the file to be closed.
If you don't find finally useful, you are probably not a defensive coder. Cleanup code (such as calling close()) belongs in a finally block. That way it is sure to be executed, no matter what happens in the try block (barring horrible death of the JVM, power failure, etc). Even if the try block throws an OutOfMemoryError or some other thing you would have no reason to catch, the cleanup code will be called.
If you don't explicitly call close(), the file will still be closed when the garbage collector invokes the destructor, but who knows when that will happen. On some systems with broken filesystem concepts (eg. win32) having an open file will prevent other cleanup operations like delete from working.
Finally is also useful if you simply want to return (or throw) within the try block. Instead of having to duplicate your cleanup code at every point where you return, or do contortions with a "retval" variable and force program flow to pass to the cleanup code before returning, just place the cleanup code in the finally block and place your return statements wherever they naturally belong in the try block. The finally block is guaranteed be invoked as execution leaves the try block, no matter how you leave the try block.
Sather's a great language, once you get use to all the SHOUTING. Pity it never caught on. I was hoping Java would pick up the implied get/set methods (i.e. x = 5 calls x.set(5)) as C# did, but I guess it's too late now.
alloca(). it allocates on the stack. in fact it is exactly what int a[1000] compiles to. it is equivalent to doing: int * a = alloca( 1000 * sizeof(int));
BSD is for people who love UNIX. Linux is for those who hate Microsoft.
Strings and chars. Let's admit it, 16-bit character was a trap. This path abandoned compactness of ASCII strings while stopping short of real "universal characters".
I say, make character values 32-bit wide, but store String internals in UTF-8. This will make charAt less efficient method than it is now, but everyone using charAt to access complete charaters now produces broken code from the i18n standpoint.
My exception safety is -fno-exceptions.
One of the things that worries me about generics is how they could be abused, or at least lead one to think things are good enough. Consider a HashMap. Because of boxing, it's really a HashMap. If you've ever looked at HashMap's code, you know it calls .hashCode() on the key objects (Integers in this case), as well as .equals(). However, if you just broke down and wrote an IntHashMap, you could iuse the int value itself as the hashcode, and use == instead of .equals(). Of course, this would no longer adhere perfectly to the Map interface which of old, but with generics, that's supposed to be a thing of the past.
Don't get me wrong, there are also benefits to generics. A lot of people forget that casting in Java is not a compile-time operation alone. It is performed at runtime and actual instructions are executed to verify the types can be casted. By using generics in collections, for example, you eliminate the need to do runtime casting, and thus eliminate the associated overhead.
Any language which cannot be redefined is, much like any programmer who says languages must not be redefined, fundamentally wrong. If you can't rewrite your language on the fly, then what good is it? :)
Signed,
A Very Happy LISP Programmer.
.
.
.
.
.
.
.
.
.
.
No, really. Redefining the language is one of those things which sounds like a bad idea, up until the time you learn functional languages. Once you grok functional languages, redefining the language becomes second nature to you: for any given serious programming task, you modify the language into a special-purpose language meant specifically for solving your problem. For instance, I wrote a crypto library in LISP recently, and I needed to do a lot of addition modulo 2**32. In any other language, I'd have to write a function to do the additions... in LISP, I just wrote a macro.
Redefining the language is an astonishingly powerful technique, and once you grok it, the idea of a language forbidding you the ability to redefine itself seems like an Apocalyptically Bad Idea.
always see something when I DON'T have moderator points. Blah!
Yow! I'm supposed to have a plan?
Java already has this capability. Java just does it in a different phase than C and C++ do. Java does it at the semantic analysis phase of compilation, whereas the C preprocessor does it before compilation even starts. In other words, in C and C++, you muck around with the source before it's compiled, but in Java, everything is parsed and then before code is generated, the compiler checks for certain sections of code that can never be reached and removes them.
To be more concrete, if you write this:
then a Java compiler should actually only emit code for the "then" part of the "if" statement. Actually, I think it's optional to do this optimization, but since Java compilers already must do pretty extensive analysis to see whether sections of code are reachable, I'd guess that most compilers do it.
By the way, I don't normally format my code with blank lines inside the "then" and "else" blocks like that, but the only way I know to get the blocks to be indented given Slashdot's limited HTML subset is to use <blockquote>...
All of these proposials have been around forever, I was attending talks on pretty much the same Generics syntax at JavaOne two or three years ago... and I've been using the same kind of enum classes since Java 1.1.
C# didn't add generics at the start as they were waiting for Java to solidify how to do them.
Also, Java has a bit more of a wait for new features since Java goes through a real standards body instead of just being defined by what Microsoft wants. And of course lots of real production code that can break if you get things wrong.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
You can use HashMap, or if you want a synchronized version wrap an instance with a Collections.synchronizedMap() call. Currently, I find collections to be about the most well-thought out part of Java and really nice to use - even better after Generics are added (which I've been waiting years for).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
who has to implement the new javac.
... wait, that would be me.
Uh,
I second that. For those interested, the pattern is described in chapter 5 of the book, "Replacing C Constructs," which is available as a free sample chapter.
The book is great, I highly recommend that you read it (the whole book, not just the sample chapters).
Sig (appended to the end of comments I post, 54 chars)
Not sure I agree. As I read it, unboxing concerns itself with primitives and their Java wrappers(int, char, boolean, etc.). In that context, it seems apropriate to transform null wrappers to the primitive defaults.
How about this bit of brain damage, culled from actual source code:
#define const
I.e., Me too dumb/lazy engineer to call or cast properly.
map { cancel; } @timerTask;
but I really do use Java's platform independence all the time, and for non-GUI applications I think it works beautifully. The key here is the 'non-GUI' ...
For cross-platform GUI applications, try IBM's SWT and JFace. Eclipse uses SWT for its GUI and it works well for me on Windows XP, Mac OS X and Red Hat Linux 8.
----- rL
Sort out the IO library (and that bloody calendar), and why can't we have a compiler switch to compile into native code :~^( Would that be so bad? Just one little switch?
Actually, what you can do is:
...
HRESULT Result = SUCCESS;
if (SUCCEEDED(Result))
{
Result = DoPart1();
}
if (SUCCEEDED(Result))
{
Result = DoPart2();
}
return Result;
You're trading horizontal space for vertical space though. But then again, it's easier for me to keep my eyes fixed and to scroll the page up/down with the mouse than to scan left and right wildly.
Make sure you understand the diff between i++ and ++i, though -- they don't behave quite the same.
...it wouldn't. And since what you really want to know is whether s equals the constant or not, this is simpler... but I'm torn about the readability thing. I usu tend to either comment stuff like this to make sure the reader understands the trick, or I just suck it up and write
...it's convenient, but I can't use it because it sucks to read, and it's kind of obscure so plenty of programmers won't understand it.
i++ and ++i both increment i, but they evaluate differently.
int i = 1;
int x = i++;
Here i is 2, and x is 1; putting the ++ after the i means "increment i after evaluating".
int i = 1;
int x = ++i;
Here i is 2, and x is also 2; "increment i before evaluating".
For the next one, I want to point out that you are NOT helping anything by using 5==x instead of x==5.
If you screw up and type
if( x = 5 )
you WILL get a compiler error because Java is stricter than C/C++ and only accepts booleans for a boolean test (not "any non-zero integer", etc. etc.).
But I have a related case where putting the things you're comparing "backwards" makes code simpler, if you can handle the confusing ordering.
String CONSTANT = "hello";
String s = null;
if( s.equals(CONSTANT) ) return 1;
This will throw a NullPointerException because you're calling a method on s.
If you used
if( CONSTANT.equals(s) ) return 1;
if (s != null && s.equals(CONSTANT) ) return 1;
It's like that ternary thing
String s = (boolValue) ? value1 : value2;
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
This is irrelevant. You'll get the compiler error either way.
(x = 5) doesn't evaluate to a boolean value any more than (5 = x) does. The compiler will choke on it because it needs a boolean for the "if" test.
You people are thinking of C/C++.... Very understandable error, but a good illustration of one of the small improvement Java made -- you're trying to fix a problem that isn't there.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
Yeah, troll, but I'll bite, because I have a nifty example of how careful Sun has been NOT to break backwards-compatibility.
It boggles the mind, but some fairly complex applets I wrote in 1996, using JDK 1.0.2 and the pre-1.1 event model still compile and run just fine in JSDK 1.4.
I'm assuming this will be the same in 1.5, but it's madness, I tell you. Madness!
The Java 1.0 event model was trickle-down -- no listeners. You had to subclass components and override methods to get events. It was horrible... but it's still fully supported (though not recommended, I'm sure).
Yes, when I ran the compilation, I got deprecation warnings out the wazoo... but it worked!
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
I fully agree with your main point, but I want to comment on this:
it pisses me off when management tells me I need to use only certains idioms in case someone comes over my code and don't understand it. I hate to have to program like the next maintainer will be clueless and ignorant.
One of the dangers of throwing in more (and more) special language features to reduce extra code is that some of them aren't going to be nearly as powerful as others. Honestly, there are (alas) programmers out there who use obscure language features simply "because it's there", to remind themselves of their cleverness. Check it out! I saved one line of code and possibly one millisecond out of a 900 millisecond operation (what do you mean, I can't go lead the new project in the Bahamas because I'm "needed here"!?).
These latest updates seem to be mostly addressing very real needs of developers, and will give us enough value to make it worth increasing the complexity of the syntax... but these updates bear *very* close watching. We should avoid adding features that will only be used very rarely... because they will affect maintainability when they are used.
It would be interesting to build a tool that would analyse my Java code and pop out a list of "rules" that any reader of my code would need to know to understand what I'm doing -- e.g.:
* the defaults of uninitialized instance variables
* evaluation of i++ vs. ++i
* path of execution of break when loops are unlabelled
* path of execution with return inside try/finally
* path of execution when throwing exception within catch block, with finally clause
* differences b/w && and & as boolean "and" (not bit-shifting).
There are lots of niggling little rules that no one knows when they first start, and while they should learn them, if I can easily avoid depending on them, I should. As more language constructs are added into the language, we're increasing the entrance barrier. Maybe with a sufficient benefit, but we should be aware of the cost.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
Seems like a troll but J++ is a pretty good editor. After a few registry tweaks, the IDE runs JRE1.4 and has no proprietary junk. Wouldn't recommend starting out anew with this app but if you've already invested any time in learning Visual Studio it can be convenient to work in a familiar environment.
switch (numBeerBottles) {
case 0:
goto safeway;
case 1:
this.drink(1);
default:
this.drink(1)+buddy.drink(1);
}
Please kindly present your proper OO design.
If you use Generics, your code will only run in 1.5 VMs. This was a marketing decision. Prototype versions of the Java compiler could previously use Generics and produce code for older virtual machines like the 1.1 VM.
r ead=389987&tstart=0&trange=15
r ead=321534&tstart=30&trange=15
Sun made this decision by itself without listening to its users and even censored its discussion. You can read about in the Generics message board:
http://forum.java.sun.com/thread.jsp?forum=316&th
http://forum.java.sun.com/thread.jsp?forum=316&th
Search for "Less memory, faster start"
http://www.apple.com/java/
As far as the C language is concerned, the null pointer is always zero; zero is a special value which tells the compiler that you mean a null pointer. The compiler may map that to any bit pattern it likes to match the underlying machine architecture, but that's completely transparent to the programmer.
That's why NULL is defined to be plain 0. Always. Not even (void *) 0, as many think, though that wouldn't do any harm. Plain zero is all that's needed. You could use plain zeroes all through your code, and it'd still be completely portable, though less readable. In fact, we all rely on it being zero every time we test for a null pointer with the ! operator!
Ceterum censeo subscriptionem esse delendam.
What's wrong with bad coding blowing up at runtime? Java's dichotomy between objects and primitive types is a defining characteristic, there's no need to cover its nakedness. From my C++ experience, genericity equals CRAPPY PERFORMANCE in time and space. Any thoughts about that? Enums are cool, but given the cosmetic nature of the other changes (Avon calling), I am skeptical. I read "Effective Java" and it contains one of my pet peeves. To paraphrase: "Don't waste your time trying to write better versions of library methods. The library programmers are way ahead of you and more competent in the first place. Just wait until they fix the current version." Fallacious and insulting. Perfection is not when nothing more can be added, but when nothing more can be taken away.
I always thought that operator overloading was evil, but I may be wrong. I'm not at familiar with scientific programming, so could you say why operator overloading is essential?
What you really want to do here is check the negated values of things, and act on those. Instead of code crawling across the page to the right, you can handle the != parts right there on the spot, and exit the routine...then you can do the next "if".
Doesn't always work, but when it doesn't it's probably time to do multiple function/method calls anyway.
Plus, it makes the code one helluva lot more readable.
While WaveSurfer doesn't have the snap of a native Windows app doing the same thing, it is OK, but I found Raven (Java/Swing) to be a bit clunky.
I'd much rather see the useful code all together than intermingled with the boilerplate error-handling code (which I don't care about if I want to understand the intended semantics). When I can't use exceptions, I prefer a macro that checks for errors and jumps to the error handling block buried at the end of the function. If you give it a nice subtle (short and lower case) name like must() you pretty much stop noticing it's there.