If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

More on Visual J#.Net

Re: More on Visual J#.Net

Visual J# sounds like the worst of both worlds. C# has nicer features then
Java when it comes to the language (properties, enums, events, etc.) and
the Java API is known and supported by millions of developers, where I doubt
any one is comfortable with over 50% of the .NET API at this time.

Visual J# combines the Java language with the largely unknown .NET API.
Do it the other way around and it would be the best platform possible in
2001: C# with the Java API.

Re: More on Visual J#.Net

I would be very suprised if Visual J# was being pushed as anything other
than a tool for migrating existing code to the .NET framework - I don't
think you'll find many people using this for new development work.

For any existing code to work, it will have to call 'native' .NET functions
via the java class library abstractions, which will slow stuff down
somewhat - but if you have a large JDK 1.1.x investment then it makes
porting a breeze.

"max caber" <maxcaber@yahoo.com> wrote in message
news:3bc476e3$1@news.devx.com...
>
> Visual J# sounds like the worst of both worlds. C# has nicer features
then
> Java when it comes to the language (properties, enums, events, etc.) and
> the Java API is known and supported by millions of developers, where I
doubt
> any one is comfortable with over 50% of the .NET API at this time.
>
> Visual J# combines the Java language with the largely unknown .NET API.
> Do it the other way around and it would be the best platform possible in
> 2001: C# with the Java API.

Re: More on Visual J#.Net

FWIW: it looks like the core Java CL is included with J# as wrappers to .NET
(albiet v1.1, not 2.0).
However, I agree. J# seems to be the VB DOS of the .NET world - IOW, a tool
to get programmers from one platform to the other.

With regards to the other point, I personally find the .NET CL much better
organized, and more functional than the Java CL, so I'm not sure I would
like to use a .NET language with a Java CL interface.

-Rob

"Ed Courtenay" <ed@edcourtenay.co.uk> wrote:
>I would be very suprised if Visual J# was being pushed as anything other
>than a tool for migrating existing code to the .NET framework - I don't
>think you'll find many people using this for new development work.
>
>For any existing code to work, it will have to call 'native' .NET functions
>via the java class library abstractions, which will slow stuff down
>somewhat - but if you have a large JDK 1.1.x investment then it makes
>porting a breeze.
>
>--
>Ed Courtenay
>http://www.edcourtenay.co.uk
>((wrong && wrong) != right)
>
>"max caber" <maxcaber@yahoo.com> wrote in message
>news:3bc476e3$1@news.devx.com...
>>
>> Visual J# sounds like the worst of both worlds. C# has nicer features
>then
>> Java when it comes to the language (properties, enums, events, etc.) and
>> the Java API is known and supported by millions of developers, where I
>doubt
>> any one is comfortable with over 50% of the .NET API at this time.
>>
>> Visual J# combines the Java language with the largely unknown .NET API.
>> Do it the other way around and it would be the best platform possible
in
>> 2001: C# with the Java API.
>
>

Re: More on Visual J#.Net

Rob Teixeira <RobTeixeira@@msn.com> wrote:
I personally find the .NET CL much better
organized, and more functional than the Java CL

Rob,
I am having a hard time learning the .NET CL because the online help, MSDN
is the best example of bloatware that I have ever come across. VB5, and
SQL 7 had great documentation. It was small, fast, easy to navigate and
contained plenty of examples. Another example of great documentation can
be found at: http://java.sun.com/j2se/1.4/docs/ap...w-summary.html

I just searched for something on my VS help and got the error: "Please Insert
Disk Labeled Visual Studio....." To bad I left that disk at home today.

The other thing to fear is MS's history of changing API's no sooner than
it takes to learn them. (This is great for my busininess, I am a trainer)
I am still teaching VB6 classes where they refer to ADO as "Universal Data
Access". Now there is ADO+ or ADO.NET or whatever they call it has replaced
ADO. Before that it was DAO and RDO. Based on past history, how long do
you think most developers think MS will support the .NET CL?

Re: More on Visual J#.Net

"max caber" <maxcaber@yahoo.com> wrote:
>
>Rob,
>I am having a hard time learning the .NET CL because the online help, MSDN
>is the best example of bloatware that I have ever come across.

Ha! I'm going to have a very hard time arguing with you there
Not that the MSDN software itself is bloatware, but there certainly is an
ENORMOUS amoung of content.
>VB5, and
>SQL 7 had great documentation. It was small, fast, easy to navigate and
>contained plenty of examples. Another example of great documentation can
>be found at: http://java.sun.com/j2se/1.4/docs/ap...w-summary.html

Agreed. But i think that in all these cases, the docs were limited and focused
only on one product. MSDN in general is pretty much documentation for all
Windows development. It's a double-edged sword in a sense. On one hand I
can complain that it can be difficult to find something until you get used
to the layout of topics, but on the other hand, it's also convenient to have
all that material in one place. I remember trying to find development documentation
for OS/2... I'll take MSDN over that any day
>The other thing to fear is MS's history of changing API's no sooner than
>it takes to learn them. (This is great for my busininess, I am a trainer)
> I am still teaching VB6 classes where they refer to ADO as "Universal Data
>Access". Now there is ADO+ or ADO.NET or whatever they call it has replaced
>ADO. Before that it was DAO and RDO. Based on past history, how long do
>you think most developers think MS will support the .NET CL?

There's an important difference here. The API themselves rarely change all
that much (with the exception of ADO), but one CL is substituted for another.
However, with the .NET CL being the core for all .NET development - and even
other parts of the .NET CL itself, I don't see that happening any time soon.
In addition, you would still be able to bind to specific versions of the
runtime.

Re: More on Visual J#.Net

"max caber" <maxcaber@yahoo.com> wrote in message
news:3bc4986e$1@news.devx.com...
>
> ADO. Before that it was DAO and RDO. Based on past history, how long do
> you think most developers think MS will support the .NET CL?

MS will support it until about 50 microseconds after
Java is dead. MS has no allegiance to anyone and
will use their own customers as human bombs
against Sun and IBM.

Microsoft - the Bin Laden of software.

Luckily, the Justice department has finally decided
to launch _Operation Enduring API_ by knocking
MS out of court.

Re: More on Visual J#.Net

Re: More on Visual J#.Net

Please Do Not Feed The Troll.

-Who Cares' Keeper-

"Who Cares?" <venetian7@home.net> wrote:
>
> MS will support it until about 50 microseconds after
> Java is dead. MS has no allegiance to anyone and
> will use their own customers as human bombs
> against Sun and IBM.
>
> Microsoft - the Bin Laden of software.
>
> Luckily, the Justice department has finally decided
> to launch _Operation Enduring API_ by knocking
> MS out of court.
>

Re: More on Visual J#.Net

>Before that it was DAO and RDO. Based on past history, how long do
>you think most developers think MS will support the .NET CL?

Actually, all those technologies you mentioned are still around and still
work fine. There are numerous ways to access databases in Windows, and each
new technology is better than the last, but they all stay around forever.
This makes the OS bigger, but it also ensures that your old software will
continue to work.

Microsoft has a great reputation for maintaining backward compatibility.
Most stuff written from VB4 on (with the exception of 16 bit controls -
UGGHHH!) will work with VB6. There are thousands of APIs that are around
from Windows 2.0 just to maintain backward compatibility. If Microsoft is
to be faulted, it is because they tend to hold on to obsolete things nearly
forever! If I am not mistaken, 16 bit applications will still run on NT
machines.

The .NET framework seems to me to be well structured and thought out over
a long time. It is also being introduced in one monolithic drop, which means
that Microsoft is able to change it in ways that will break compatibility
right up to the official delivery of VS7. This is unlike the Java framework,
which has evolved over many years. Have you looked at the basic file manipulation
objects? If you delete a file, it returns True if the operation succeeded
- HELLOOOOOO, use an EXCEPTION! But it is that way because it was written
a long time ago by a programmer who had been plucked from the C/C++ world,
and now lots of code depends on it.

.NET has a big learning curve, but once you get familiar with it, all kinds
of development is going to be a lot easier than it ever was before.

The question you should be asking is not, "How long will it be before Microsoft
gives up these silly new ideas," but, "Why did Microsoft devote its entire
corporation to developing .NET?" The answer has something to do with some
of the disadvantages of statically compiling code, and the direction of programming
(web, dynamic updates, zero-impact installations, etc.), from single-user
machines to networks of thick-client applications that must be centrally
managed.

There are simply things that Microsoft needed to be able to do that traditional
VB and C++ programming could not touch. That is why .NET is here, that is
why Microsoft bet the company on it, and that is why it will still be here
when VB6 is a memory and C++ is only used by metalheads for ring 0 programming.

Re: More on Visual J#.Net

On 11 Oct 2001 15:46:35 -0700, "Jason"
<jason@creative_nospam_corp.com> wrote:
>There are simply things that Microsoft needed to be able to do that traditional
>VB and C++ programming could not touch. That is why .NET is here, that is
>why Microsoft bet the company on it, and that is why it will still be here
>when VB6 is a memory and C++ is only used by metalheads for ring 0 programming.

So how do you intend to convince the three million classic VB
programmers to dump their religion overnight and become converted to
another faith. For that's what it amounts to. You'd have more luck
converting them to Pascal. Oh, wait a mo, that's what many are gonna
be doing anyways!