Mustang jdk1.6 build 61 on jbuilder 2005
Raj
I have downloaded and installed the Mustang JDK build 61, and installed it into JBuilder 2005. When I try to compile I get 70 build errors of the form:
"MyFile.java": cannot access java.lang.Object; bad class file: C:\java\jdk6.0_b61\jre\lib\rt.jar\java\lang\Object.class, class file has wrong version 50.0, should be 49.0, Please remove or make sure it appears in the correct subdirectory of the classpath. at line 17, column 1
The bad classes reported are everything from java.lang.Object, to util classes, and Swing classes.
Now, I can tell JBuilder to use the mustang javac, and this works fine. But then all the code insight and editor error trapping functions constantly report errors, rendering the editor useless beyond being a text editor/typewriter.
Any thoughts? Or does Jbuilder simply not allow use of Mustang yet?
Raj.
Bill Joy
its delivered class files in the JDK for Mustang. This is supposed to only
be done when there is a change in the Java language or the class file
format.
Since no tool can be upward-compatible to some unknown future version, the
response is what you are seeing.
There is no way in JBuilder 2005 (or JBuilder 2006 for that matter) for you
specify a target VM beyond JDK 5. So I suggest you configure your project
to use JDK 5.0 or earlier to build so things like CodeInsight will work.
In order to run your project on Mustang, create a run configuration and tell
it to use your Mustang JDK rather than the project JDK via Run |
Configurations | New or Edit | JDK.
If there is some API change in Mustang you must use, you will have to find
some way to workaround the problem. (One potential approach is to use the
Import Source wizard and pull in the source for the Mustang JDK class with
the API change you want to use plus anything else that has changed which it
needs to compile under JDK 5.0. That way the compiler will see the local
compiled version and you will not have to have Mustang-compiled classes on
your classpath during build.)
"Raj" <r...@beagle-2.net> wrote in message
news:438a45a6$1...@newsgroups.borland.com...
Paul Nichols [TeamB]
>
> Any thoughts? Or does Jbuilder simply not allow use of Mustang yet?
>
> Raj.
Since Mustang was not even a work in progress during the release of JB
2005, how would you expect JB 2005 to support it?
The problem you are having, is the same one we would have anytime you move
from an older version of the SDK to a newer version. The version info on
the compiled class changes. That is why you are getting the version not
supported error.
TO make this work (and it will change before release no doubt, always has),
is to rebuild all of the open tools and compilers to be aware of the new
compilation and version info. Not a task I would want to undertake :)
Alexey N. Solofnenko
to set to make JBuilder "understand" whatever format people want? If
newer formats do not work - it will be their fault, but the history
shows that SUN changes class file format version just to make sure that
nobody tries to run new code with old VMs while keeping the format
itself backward (and forward) compatible.
- Alexey.
--
Alexey N. Solofnenko
home: http://trelony.cjb.net/
Raj Nagappan
Let me repost that with line breaks...
Thank you for all the responses.
On one hand I understand that JBuilder cannot pre-empt new
language versions and be forward-compatible. But on the other
hand I think it should! You can configure new JDKs, so I don't
see why you shouldn't be allowed to go up to the next full
version. JBuilder should have an option to gracefully do the
best it can until a product update ships.
I do need to use some of the new Mustang features, and I will
need to work with them fairly regularly. Over the past 24 hrs I
have been testing out IntelliJ Idea, which supports the current
Mustang build. I quite like it, but having been a JBuilder user
for some 5 or 6 years I will need to play with it a bit more
before I pass judgement.
Raj.
Raj Nagappan
Thank you for all the responses.
On one hand I understand that JBuilder cannot pre-empt new language versions and be forward-compatible. But on the other hand I think it should! You can configure new JDKs, so I don't see why you shouldn't be allowed to go up to the next full version. JBuilder should have an option to gracefully do the best it can until a product update ships.
I do need to use some of the new Mustang features, and I will need to work with them fairly regularly. Over the past 24 hrs I have been testing out IntelliJ Idea, which supports the current Mustang build. I quite like it, but having been a JBuilder user for some 5 or 6 years I will need to play with it a bit more before I pass judgement.
Raj.
Ken Warner
> Let me repost that with line breaks...
>
> Thank you for all the responses.
>
> On one hand I understand that JBuilder cannot pre-empt new
> language versions and be forward-compatible. But on the other
> hand I think it should! You can configure new JDKs, so I don't
> see why you shouldn't be allowed to go up to the next full
> version. JBuilder should have an option to gracefully do the
> best it can until a product update ships.
>
> I do need to use some of the new Mustang features, and I will
> need to work with them fairly regularly. Over the past 24 hrs I
> have been testing out IntelliJ Idea, which supports the current
> Mustang build. I quite like it, but having been a JBuilder user
> for some 5 or 6 years I will need to play with it a bit more
> before I pass judgement.
>
> Raj.
Raj,
Tell us what you think about IntelliJ. I also think that the ability to
adapt to new Java releases should be a built in feature of JB. Eclipse
does it...
Paul Nichols [TeamB]
> ... and every time time people ask for that. Why not to have an option
> to set to make JBuilder "understand" whatever format people want? If
> newer formats do not work - it will be their fault, but the history
> shows that SUN changes class file format version just to make sure that
> nobody tries to run new code with old VMs while keeping the format
> itself backward (and forward) compatible.
>
> - Alexey.
>
You can do this by changing the compiler options, but the Open Tools and
some of the debugging actions will not work. You cannot set break points,
etc., because these tools have to be built and tested on a compiled version
of the underlying compiler.
You can of course, use 1.6 beta, if you wish, to run and compile your
applications. Just have the knowledge that before you do, you will not have
all of your normal debugging and IDE features working. Doesn't matter what
IDE you use, whether Eclipse, NetBeans, JDeveloper, etc. Using an
unsupported JVM will cause mild to severe bugs and instability in the IDE.
David Orriss, Jr. [TeamB]
> Tell us what you think about IntelliJ. I also think that the ability to
> adapt to new Java releases should be a built in feature of JB. Eclipse
> does it...
IntelliJ and Eclipse only do it when they're updated to. You can try
Mustang with Eclipse 3.1, but if (more like *when*) you have problems, the
Eclipse group will basically say "you have to wait until we actually
support it in the product).
I mean seriously, Ken, how can an IDE *possibly* support a JDK before the
specs are even final?
--
David Orriss Jr. [TeamB]
http://www.codethought.com
* Please limit all responses to the newsgroups. Thanks! *
The JBuilder Webring is dead - long live the JBuilder Webring.
My blog: http://mywebpages.comcast.net/daorriss/
Save yourself some time and check these sites:
Borland Newsgroup Search:
http://www.borland.com/newsgroups/ngsearch.html
Joi Ellis's Faq-O-Matic:
http://www.visi.com/~gyles19/fom-serve/cache/1.html
Ken Warner
> On Mon, 28 Nov 2005 16:03:27 -0800, Ken Warner wrote:
>
>
>>Tell us what you think about IntelliJ. I also think that the ability to
>>adapt to new Java releases should be a built in feature of JB. Eclipse
>>does it...
>
>
> IntelliJ and Eclipse only do it when they're updated to. You can try
> Mustang with Eclipse 3.1, but if (more like *when*) you have problems, the
> Eclipse group will basically say "you have to wait until we actually
> support it in the product).
>
> I mean seriously, Ken, how can an IDE *possibly* support a JDK before the
> specs are even final?
>
So I guess you are speaking for Boland's tactic of waiting until a JDK
is released to the public rather than working as closely as possible
with SUN during development to assure that their IDE is updated in a
timely manner.
If SUN releases a JDK -- even beta -- the specs have to be pretty solid
or else their development team wouldn't be able to work together even to
release a beta. The specs should be solid enough to support at least
preliminary integration with an IDE -- but you have to be smart. The
cop out is to say that Borland is not smart enough. Is that what you
are saying? That Borland isn't smart enough?
David Orriss, Jr. [TeamB]
> Is that what you
> are saying? That Borland isn't smart enough?
Don't put words in my mouth. What I said was you were making incorrect
claims and assumptions. I was just trying to be polite about it.
Raj Nagappan
My point is that support for intermediate releases would
be very much appreciated by those of us who need new features
in Mustang. I don't mind waiting 2 months until the IDE supports
the next beta, the point is I don't have wait 1 year and 2 months
for the JDK to go into full production.
Having worked with both Idea and Jbuilder over the last few days
there are things that I like about both. Will post a better
comparision in a few weeks for those that requested it.
Raj.
Paul Nichols[TeamB]
"Raj Nagappan" <r...@beagle-2.net> wrote in message
news:438e3e38$1...@newsgroups.borland.com...
>
> My point is that support for intermediate releases would
> be very much appreciated by those of us who need new features
> in Mustang. I don't mind waiting 2 months until the IDE supports
> the next beta, the point is I don't have wait 1 year and 2 months
> for the JDK to go into full production.
The problem is that you have to wait until the final specifications for the
final delivery are code locked. In other words, the SDKis no longer in
design or feature flux and reasonable stability have been established (aka a
release candidate).
True I have seen some other IDEs support beta JDKs, only to see these same
IDEs to break miserably using the JDK version when it was finally released.
Seem to recall that both NetBeans and Eclipse went through this in earlier
version with 1.5.
It is impossible to stabalize an IDE environment with changing
specifications on beta VMs. That would be like saying, but yeah, I want your
beta application to work PRECISLEY like the final application. To quote a
southern familiar southern venacularism, "That ain't gonna happen." for all
but the simplist f applications.
Does Borland prepare for the eventual release of a JDK/VM? I would feel
reasonable assure they must and are. But would I want to purchase a
commecial IDE built on Beta VMs? I think I would spend my money some other
"stable" way. :)
Of course, nothing precludes you from working with 1.6 beta, nor on it. The
IDE will certainly compile the code (if you change your default compile
options) and you can edit it and recompile your 1.6 code in the IDE, until
your heart is content. Just do not count on all of the IDE goodies working:
like debugging, code completion, wizards, etc. There is no simply no way
anyone can finalize Open Tools or plugins until the VM itself is
finalized.
Of course, you are free to write your own :)
Alexey N. Solofnenko
look an other IDEs because JBuilder does not support what they need?
Maybe only few people are interested in Java 6, then it maybe easier for
Borland to reject them.
- Alexey.
--
Ken Warner
> There is also another question - does Borland want developers actively
> look an other IDEs because JBuilder does not support what they need?
> Maybe only few people are interested in Java 6, then it maybe easier for
> Borland to reject them.
>
> - Alexey.
>
Alexey,
The replies you get here from TeamB are really not from Borland. TeamB
seems to disassociate itself from Borland when pressed on issues like this.
The old time programmers on this list know that there are ways to keep
up with changing specs. But that requires the will to do so and Borland
doesn't seem interested. In the mean time, about the best we will get
are the Borland appologists asking us why we don't see it their way...
David Orriss, Jr. [TeamB]
> The old time programmers on this list know that there are ways to keep
> up with changing specs. But that requires the will to do so and Borland
> doesn't seem interested. In the mean time, about the best we will get
> are the Borland appologists asking us why we don't see it their way...
Speaking as one of those "old time programmers" I would be inclined to
agree. However, where do you put the development dollars? In tools that
have support for technologies like EJB, Web, XML and SOA's or in constantly
updating the tool to make sure the latest and greatest beta of the JDK is
supported? I'm sure if you were the VP in charge of Java tools development
you would have different priorities from the current management.
Bottom line - it's technically possible and financially prohibitive to do
what you're suggesting. No apologies here. It's just simple facts and
dollars.
Ken Warner
>
>
>>The old time programmers on this list know that there are ways to keep
>>up with changing specs. But that requires the will to do so and Borland
>>doesn't seem interested. In the mean time, about the best we will get
>>are the Borland appologists asking us why we don't see it their way...
>
>
> Speaking as one of those "old time programmers" I would be inclined to
> agree. However, where do you put the development dollars? In tools that
> have support for technologies like EJB, Web, XML and SOA's or in constantly
> updating the tool to make sure the latest and greatest beta of the JDK is
> supported? I'm sure if you were the VP in charge of Java tools development
> you would have different priorities from the current management.
>
> Bottom line - it's technically possible and financially prohibitive to do
> what you're suggesting. No apologies here. It's just simple facts and
> dollars.
>
Yup! All about the bottom line. Or you could hire me as VP of
Development :-)
David Orriss, Jr. [TeamB]
> Yup! All about the bottom line. Or you could hire me as VP of
> Development :-)
Hey man.. if only I was cutting the checks.. ;)
Raj Nagappan
>where do you put the development dollars? In tools that
>have support for technologies like EJB, Web, XML and SOA's or in constantly
>updating the tool to make sure the latest and greatest beta of the JDK is
>supported? I'm sure if you were the VP in charge of Java tools development
>you would have different priorities from the current management.
>
>Bottom line - it's technically possible and financially prohibitive to do
>what you're suggesting. No apologies here. It's just simple facts and
>dollars.
Over the last couple of days since I first posted this I have
started forming the opinion that JBuilder might *not* be the
product for me anymore. I am not a multi-national who has to
hot-swap WARs, EARs, JSPs, etc. I am part of a small company
working on code-centric desktop java applications. Maybe
I'm not in Jbuilder's target market anymore?
This heated debate has really surprised me; I only expected a
couple of responses that said either "yes we support the beta,
here's how..." or "no, not interested". To add my two cents
worth, since my original post I have learned that JBuilder is
eventually going to be a tool on top of the Eclipse platform,
so that makes things even more confusing.
I personally think that it's a cop out to not support the
Mustang beta. Whatever the beta policy was in the past, Mustang
is publicly available and has had over 60 beta builds. I would
say that most of the bugs are shaken out by now.
At the very least, JBuilder should allow you to turn off some
aspects of ErrorInsight, etc, that cause all the design time
problems.
Raj.
Ken Warner
I sense a disturbance in the Force -- there is a definite tug on the
middle of my nerd soul to look at Eclipse. I'm even smaller than you.
I'm an independent with micro-bucks. I wait for Foundation to come
around. But Foundation -- instead of being the first thing out the gate
-- is always the last. AND always way late on the Java release curve.
I mean, I'm waiting for Java 5 and Java 6 is already strong beta!
What's up with that (to coin a phrase)?