对 Date 的引用不明确 英文,怎么处理?

5350人阅读
&今天在没事,跟着尚学堂写一个论坛的程序。在写入时间时,发现了问题。在建立MySQL表使,发帖时间用的datetime类型。并且用系统函数now()来实现。在java实体类中用的java.util.date类型。发现这是犯愁了,众所周至,java中时间类型一直是让人头疼的一个问题。
&&硬着头皮上,终于发现原来Hibernate已经帮我们解决了问题。
MySQL简表语句如下:&
create&database&use&create&table&article&(id&int&primary&key&auto_increment,pid&int,rootid&int,title&varchar(255),cont&text,pdate&datetime,isleaf&int&#1-not&leaf&0-leaf);insert&into&article&values&(null,&0,&1,&'蚂蚁大战大象',&'蚂蚁大战大象',&now(),&1);insert&into&article&values&(null,&1,&1,&'大象被打趴下了',&'大象被打趴下了',now(),&1);insert&into&article&values&(null,&2,&1,&'蚂蚁也不好过','蚂蚁也不好过',&now(),&0);insert&into&article&values&(null,&2,&1,&'瞎说',&'瞎说',&now(),&1);insert&into&article&values&(null,&4,&1,&'没有瞎说',&'没有瞎说',&now(),&0);insert&into&article&values&(null,&1,&1,&'怎么可能',&'怎么可能',&now(),&1);insert&into&article&values&(null,&6,&1,&'怎么没有可能',&'怎么没有可能',&now(),&0);insert&into&article&values&(null,&6,&1,&'可能性是很大的',&'可能性是很大的',&now(),&0);insert&into&article&values&(null,&2,&1,&'大象进医院了',&'大象进医院了',&now(),&1);insert&into&article&values&(null,&9,&1,&'护士是蚂蚁',&'护士是蚂蚁',&now(),&0);
实体类如下:
package&import&java.util.D/**&*&Article&entity.&*&&*&@author&smartcat86&*/public&class&Article&implements&java.io.Serializable&{&&&&//&Fields&&&&private&Integer&&&&&private&Integer&&&&&private&Integer&&&&&private&String&&&&&private&String&&&&&private&Date&&&&&private&Integer&&&&&//&Constructors&&&&/**&default&constructor&*/&&&&public&Article()&{&&&&}&&&&/**&full&constructor&*/&&&&public&Article(Integer&pid,&Integer&rootid,&String&title,&String&cont,&&&&&&&&&&&&Date&pdate,&Integer&isleaf)&{&&&&&&&&this.pid&=&&&&&&&&&this.rootid&=&&&&&&&&&this.title&=&&&&&&&&&this.cont&=&&&&&&&&&this.pdate&=&&&&&&&&&this.isleaf&=&&&&&}&&&&//&Property&accessors&&&&public&Integer&getId()&{&&&&&&&&return&this.&&&&}&&&&public&void&setId(Integer&id)&{&&&&&&&&this.id&=&&&&&}&&&&public&Integer&getPid()&{&&&&&&&&return&this.&&&&}&&&&public&void&setPid(Integer&pid)&{&&&&&&&&this.pid&=&&&&&}&&&&public&Integer&getRootid()&{&&&&&&&&return&this.&&&&}&&&&public&void&setRootid(Integer&rootid)&{&&&&&&&&this.rootid&=&&&&&}&&&&public&String&getTitle()&{&&&&&&&&return&this.&&&&}&&&&public&void&setTitle(String&title)&{&&&&&&&&this.title&=&&&&&}&&&&public&String&getCont()&{&&&&&&&&return&this.&&&&}&&&&public&void&setCont(String&cont)&{&&&&&&&&this.cont&=&&&&&}&&&&public&Date&getPdate()&{&&&&&&&&return&this.&&&&}&&&&public&void&setPdate(Date&pdate)&{&&&&&&&&this.pdate&=&&&&&}&&&&public&Integer&getIsleaf()&{&&&&&&&&return&this.&&&&}&&&&public&void&setIsleaf(Integer&isleaf)&{&&&&&&&&this.isleaf&=&&&&&}}
package&public&class&Test&{&&&&&&&&public&static&void&main(String[]&args){&&&&&&&&&&&&&&&&&&&&&&DBOperate&dbo&=&new&DBOperate(HibernateSessionFactory.getSession());//数据库操作类&&&&&Article&a&=&new&Article();&&&&&&&&&a.setId(null);//Hibernate中使native使其自动增加&&&&&a.setPid(pid);&&&&&a.setRootid(rootId);&&&&&a.setTitle(title);&&&&&a.setCont(cont);&&&&&&&&&&a.setPdate(new&Date());&&&&a.setIsleaf(0);&&&&&&&&dbo.insert(a);&&&&}&&&&}
后经过测试,插入时间为: 04:04:36.0,和使用 new java.text.SimpleDateFormat("yy-MM-dd HH:mm:ss").format(new java.util.date())得出的结果一样。
当然从数据库读出来了可以使用SimpleDateFormat类来实现。
参考知识库
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
访问:311941次
积分:3413
积分:3413
排名:第6795名
原创:50篇
转载:82篇
评论:26条
(1)(2)(10)(3)(5)(14)(18)(13)(4)(9)(8)(3)(1)(1)(3)(5)(10)(2)(4)(14)(2)当前位置: →
→ 对Date的引用不明确,java.util中的类java.util.Date和java.sql中的类java.sql.Date都匹配,该如何处理
对Date的引用不明确,java.util中的类java.util.Date和java.sql中的类java.sql.Date都匹配,该如何处理
& 作者:佚名 & 来源: 互联网 & 热度:
&收藏到→_→:
摘要: 对 Date的引用不明确,java.util中的类java.util.Date和java.sql中的类java.sql.Date都匹配因为编码需要数据库和得到当前时间,...
"对Date的引用不明确,java.util中的类java.util.Date和java.sql中的类java.sql.Date都匹配,该如何处理"::
对 date的引用不明确,java.util中的类java.util.date和java.sql中的类java.sql.date都匹配因为编码需要和得到当前时间,所以引用了&%@page import=&java.sql.*& %&和&%@page import=&java.util.*& %&但是在执行&%date today=new date();%&这一句时,提示了如下错误“对 date 的引用不明确,java.util 中的 类 java.util.date 和 java.sql 中的 类 java.sql.date 都匹配”敢问高手们,这该怎么办?巨谢!------解决方案--------------------import=&java.util.date&
------解决方案--------------------java中有两个date类,一个是util的,一个是sql里的。如果你两个都导入了,在你使用的时候必须加上前缀,这就可以说明你用的是哪个date类了。比如:java.sql.date date =new date();//包名+类名这样子就可以清晰地表明你用的是哪个包里的类了。
------解决方案--------------------类名冲突了,楼上正解 搜索此文相关文章:此文来自: 马开东博客
网址: 站长QQ
上一篇:没有了
对Date的引用不明确,java.util中的类java.util.Date和java.sql中的类java.sql.Date都匹配,该如何处理_JavaWeb相关文章
JavaWeb_总排行榜
JavaWeb_最新
JavaWeb_月排行榜
JavaWeb_周排行榜
JavaWeb_日排行榜如果一个类里面同时引用了 java.util.Date 和 java.sql.Date 这个两个包,请问声明的时候该怎么使用呢?_百度知道
如果一个类里面同时引用了 java.util.Date 和 java.sql.Date 这个两个包,请问声明的时候该怎么使用呢?
还有什么别的办法.util.util.Date date = new java.Date()。谢谢除了 java
提问者采纳
java.util.sql,这种有什么不好的.util. 除了这个应该没了吧java.Date date = new java.Date date = new java.Date().Date()
来自团队:
其他类似问题
为您推荐:
其他4条回答
没有别的办法了吧。
没有别的办法了亲
没别的办法了
没在工具中有很多容易错误,另外注意命令提示符要回到包这个文件夹的上层目录。
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁Java API的Date, Calendar日期处理相关类分析 - 笨笨 - 博客园
随笔 - 636, 文章 - 0, 评论 - 469, 引用 - 13
在计算机程序中精确的处理日期是困难的。不仅有显而易见的(英语: January, 法语: Janvier, 德语: Januar, 等)国际化需求, 而且得考虑不同的日期系统(并非所有的文化都用基督耶稣的生日作为纪年的开始)。如有高精度或非常大规模的时间需要被处理, 就有额外的方面需要被注意,比如闰秒或时间系统的变化。(公历(阳历, 格里高利历法)在西方被普遍接受是在1582年,但并非所有的国家在同一天接受!)
尽管有关于闰秒, 时区, 夏令时, 阴历的问题, 度量时间却是一个非常简单的概念: 时间的进行是线性的很容易被忽略。一旦时间轴的区域被定义, 任何时间点被从起点时间的流逝就可以确定。这和地理位置或当地时区是独立的 – 对任意指定的时间点, 对任意地区, 从起点的过程是相同的(忽略相对论的矫正)。
--------------------------------------------------------------------------------
可当我们试图根据某些日历解释这一时间点的时候困难来了, 比如, 根据月, 日, 或者年来表示它。在这一步上地理信息变得相关: 在时间上的同一个点对应不同的天的某一时间, 依赖于区域 (比如: 时区)。基于解释日期的修正经常是必要的(今天一个月以后是哪一天?) 并且增加了额外的困难: 上溢和下溢(12月15号的后一个月是下一年), 且不明确(1月30号后的一个月是哪一天?).
在最初的JDK 1.0, 一个时间点, 通过把它解释为java.util.Date类, 它被计算在一起来表示. 虽然相对容易处理, 但它并不支持国际化; 从JDK 1.1.4 或JDK 1.1.5, 多样的负责处理日期的职责被分配到以下类中:
java.util.Date
代表一个时间点.
abstract java.util.Calendar
java.util.GregorianCalendar extends java.util.Calendar
解释和处理Date.
abstract java.util.TimeZone
java.util.SimpleTimeZone extends java.util.TimeZone
代表一个任意的从格林威治的偏移量, 也包含了适用于夏令时(daylight savings rules)的信息.
abstract java.text.DateFormat extends java.text.Format
java.text.SimpleDateFormat extends java.text.DateFormat
变形到格式良好的, 可打印的String, 反之亦然.
java.text.DateFormatSymbols
月份, 星期等的翻译, 作为从Locale取得信息的一种替代选择.
java.sql.Date extends java.util.Date
java.sql.Time extends java.util.Date
java.sql.Timestamp extends java.util.Date
代表时间点, 同时为了在sql语句中使用也包含适当的格式.
注意: DateFormat 和相关的类在java.text.*包. 所有的java.sql.*包中日期处理相关类继承了java.util.Date类. 所有的其它类在java.util.*包中.
这些&新&类来自三个分离的继承层次, 其顶层类(Calendar, TimeZone, and DateFormat)是抽象的. 针对每一个抽象类, Java标准类库提供了一个具体的实现.
java.util.Date
类java.util.Date代表一个时间点. 在许多应用中, 此种抽象被称为&TimeStamp.& 在标准的Java类库实现中, 这个时间点代表Unix纪元January 1, :00 GMT开始的毫秒数. 因而概念上来说, 这个类是long的简单封装.
根据此种解释, 类中仅有的没有过期的(除了那些毫秒数的get和set方法)是那些排序方法.
这个类依靠System.currentTimeMillis() 来取得当前的时间点. 因此它的准确度和精度由System的实现和它所调用底层(本质是操作系统)决定.
The java.util.Date API
在最初的 Date类使用中名字和约定引起了无尽的混淆. 然而用0-11计算月, 从1900计算年的决定模仿了C标准类库的习惯, 调用函数 getTime()返回起始于Unix纪元的毫秒数和 getDate()返回星期的决定显然是Java类设计者自己的.
java.util.Calendar
Calendar代表一个时间点(一个&Date&), 用以在特定的区域和时区适当的解释器. 每一个Calendar 实例有一个包含了自纪元开始的代表时间点的long变量.
这意味着Calendar 不是一个(无状态) 变换者或解释器, 也不是一个修改dates的工厂. 它不支持如下方式:
Month Interpreter.getMonth(inputDate) or
Date Factory.addMonth(inputDate)
Instead, Calendar实例必须被初始化到特定的Date. 此Calendar实例可以被修改或查询interpreted属性.
奇怪的是, 此类的instances 总是被初始化为当前时间. 获得一个初始化为任意Date的Calendar 实例是不可能的—API强制程序员通过一系列的在实例上的方法调用, 比如setTime(date)来显式的设置日期.
访问Interpreted 字段和类常量
Calendar类遵从一不常用的方式来访问interpreted date实例的单个字段. 而不是提供一些dedicated属性 getters和setters方法(比如getMonth()), 它仅提供了一个, 使用一个标示作为参数来获取请求的属性的方法:
int get(Calendar.MONTH) 等等.
注意这个函数总是返回一个int!
这些字段的标示符被定义为Calendar类的public static final变量. (这些identifiers是raw的整数, 没有被封装为一个枚举抽象.)
除了对应这些字段标示(键值), Calendar 类定义了许多附加的public static final 变量来保存这些字段的值. 因此, 为测试某一特定date (由Calendar 的实例calendar表示) 是否在一年的第一个月, 会有像如下的代码:
if (calendar.get(Calendar.MONTH) == Calendar.JANUARY) {...}
注意月份被叫做 JANUARY, FEBRUARY, 等等, 不管location(相对更中性的名字比如: MONTH_1, MONTH_2, 等等). 也有一个字段UNDECIMBER, 被一些(非公历(阳历, 格里高利历法))日历使用, 代表一年的第十三个月.
不幸的是, 键值和值既没有通过名字也没分组成嵌套的inerface来区分.
Calendar提供了三种办法来修改当前实例代表的日期: set(), add(), 和roll(). set()方法简单的设置特定的字段为期望的值. add() 和 roll() 的不同在于它们处理over- and underflows: add() 传递变更到&较小&或&较大&的字段, 而roll()不影响其它字段. 比如, 当给代表12月15号的Calendar实例增加一个月, 当add()使用年会增加, 但使用roll()不会发生任何变化. 为每一种case对应一个函数的决定的动机是, 它们可能在GUI中不同的使用情形.
由于Calendar的实现的方式, 它包含冗余的数据: 所有的字段都可以从给定的时区和纪元开始的毫秒数计算出来,反之亦然. 这个类为这些操作分别定义了抽象方法computeFields()和computeTime(), 又定义了complete()方法执行完全的来回旅程. 因为有两套冗余的数据, 这两套数据可能不同步. 根据类的JavaDoc文档, 当发生变更的时候依赖的数据以lazily 的方式重新计算. 当重新计算需要的时候, 子类必须维护一套脏数据标志作为符号.
--------------------------------------------------------------------------------
实现的Leakage
对于一个”新”的日期相关处理类, 不得不说实现的细节在某种程度上被泄漏到了API中. 在这点上, 这是它们有意用作基类的自定义开发的反映, 但它也偶然看出是不充分清晰设计一个公共接口的结果.Calendar 抽象是否维护两个冗余数据集合完全是一个实现的细节, 因而应当对客户类隐藏. 这也包括打算通过继承来重用此类.
附加的功能
Calendar基类提供的附加功能分成三类. 几个静态的工厂方法来获得用任意时区和locales初始化的实例. 如前面提到的, 所有以这种方式获得实例已经被初始化为当前时间. 没有工厂方法被提供来获得初始化为任意时间点的实例.
第二组包含before(Object)和after(Object)方法. 它们接受Object类型的参数, 因而允许这些方法被子类以任意类型的参数覆盖掉.
最后, 有许多附加的方法来获得设置附加的属性, 比如当前的时区. 当中有几个用以查询特定字段在当前Calendar实现下的可能和实际的最大、最小值.
java.util.GregorianCalendar
GregorianCalendar 是仅有可用的Calendar的子类. 它提供了基础Calendar抽象适合于根据在西方的习惯解释日期的实现. 它增加了许多public的构造函数, 也有针对于Gregorian Calendars的方法, 比如isLeapYear().
java.util.TimeZone 和 java.util.SimpleTimeZone
TimeZone类和其子类是辅助类, 被Calendar用以根据选择的时区来解释日期. 按字面意思来说, 一个时区表示加到GMT上后到当前时区的一定的偏移. 显然, 这个偏移在夏令时有效的时候会发生变化. 因而为了计算对于给定日期和时间的本地时间, TimeZone抽象不仅需要明白当DST有效时的额外偏移, 而且还需明白什么时候DST有效的规则.
抽象基类TimeZone 提供了基本的处理&raw&(没有考虑夏令时)实际偏移(用毫秒数!)的方法, 但任何关于DST规则的功能实现被留给了子类, 比如SimpleTimeZone. 后者提供了许多方法来指定控制DST开始和结束的规则, 比如在一个月中明确的某一天或某一天随后的周几. 每一个TimeZone 有一个可读的, 本地无关的显示名. 显示名以两种风格: LONG和SHORT呈现.
星期的开始?
Calendar的文档投入了相当的文字来正确的计算月或年中的weeks. weekday 被认为是一周的开始在因国家的不同而不同. 在美国, 一周通常被认为从周日开始. 在部分欧洲国家一周从周一开始结束于周日.这将影响到哪一周被认为是在一年(或月)第一个完整的周, 和计算一年的周数.
时区由一标示字符串明确的决定. 基类提供静态方法String[] getAvailableIDs()来获得所有已知安装(JDK内带有)的标准时区. (在我的安装内有557个, JDK1.4.1) 假如需要, JavaDoc 定义了严格的建立自定义时区标示符的语法. 也提供了静态工厂方法用以获取 — 指定ID或缺省的当前时区的TimeZone 实例. SimpleTimeZone提供了一些公有的构造函数, 奇怪的是对于一个抽象类, 如TimeZone. (JavaDoc 写到 &子类构造函数调用.& 显然, 应该声明为protected.)
java.text.DateFormat
尽管Calendar和相关类处理locale-specific日期的解释,仍有DateFormat 类辅助日期和(人类)可阅读字符串之间的变换. 表示一个时间点时, 会出现附加的本地化问题: 不仅仅在语言, 而且日期格式是地区独立的(美国: Month/Day/Year,德国: Day.Month.Year, 等等). DateFormat 尽力地为程序员管理这些不同.
抽象基类DateFormat不需要(且不允许) 任意的, 程序员定义的日期格式. 作为替代, 它定义了四种格式化风格: SHORT, MEDIUM, LONG, 和FULL (以冗余增加的顺序).对一给定locale和style, 程序员可依靠此类获取适当的日期格式.
抽象基类DateFormat 没有定义静态方法来完成文本和日期之间的格式化和转换. 作为替代, 它定义了几个静态工厂方法来获取被初始化为给定locale和选定style的实例. 既然标准的格式化总是包含日期和时间, 附加工厂方法可用来获取仅处理时间或日期部分的实例. String format(Date)和Date parse(String) 方法然后执行变形. 注意具体的子类可以选择打破这种习惯.
在其内部使用, 解释日期的Calendar对象是可访问和修改的, TimeZone和NumberFormat对象也同样. 然而, 一旦DateFormat 被实例化locale和style就不能再修改.
亦有可用的(抽象的)用以拼接的字符串解析和格式化的方法, 分别接受额外的ParsePosition或FieldPosition参数. 这些方法的每一个都有两个版本. 一个接受或返回Date实例另一个接受或返回普通的Object, 来允许在子类中有选择性的处理Date. 它定义了一些以_FIELD 结尾的public static变量来标示多种可能和FieldPosition一起使用的变量(cf. java.util.Format的Javadoc).
仅有且最常用的DateFormat类的具体实现是SimpleDateFormat. 它提供了所有上述的功能, 且允许定义任意的时间格式. 有一套丰富语法来指定格式化模式; JavaDoc提供了所有细节. 模式可以被指定为构造函数的参数或显式的设置.
Printing a Timestamp: A Cut-and-Paste Example
想象你要用用户定义的格式打印当前的时间; 比如, 到log文件. 以下就是做这些的:
// 创建以下格式的模式: Hour(0-23):Minute:Second
SimpleDateFormat formatter = new SimpleDateFormat( &HH:mm:ss& );
Date now = new Date();
String logEntry = formatter.format(now);
// 从后端读入
Date sometime = formatter.parse(logEntry);
} catch ( ParseException exc ) {
exc.printStackTrace();
注意需要被catch的ParseException. 当输入的字符串不能被parse的时候被抛出.
java.sql.*相关类
在java.sql.*包中的日期时间处理类都继承了java.util.Date. 事实上它们三个反映了三种标准SQL92模型的类型需要DATE, TIME, and TIMESTAMP.
像java.util.Date, SQL包中的这三个类是表示一个时间点的数字的简单封装. 分别地Date和Time类忽略关于一天中的时间或日历的日期.
可Timestamp类, 不仅包含到毫秒精度, 通常的时间和日期, 而且允许存储附加的精确到纳秒精度的时间点的数据. (纳秒是一秒的十亿分之一)
除了影射对应的SQL数据类型, 这些类处理与SQL一致的字符串表示的转换. 在这一点, 这三个类中的每一个覆盖了toString()方法. 此外, 每个类提供了静态的工厂方法, valueOf(String), 返回被初始化为传递参数字符串表示的时间的当前调用类的实例. 这三个方法的字符串表示的格式已被SQL标准选定, 且不能被程序员改变.
存储纳秒需要的额外数据, 没有很好的与在Timestamp中其它通常的时间和日期信息的表示一致. 比如, 在Timestamp实例上调用 getTime() 将返回自Unix纪元开始的毫秒数,忽略了纳秒数据. 简单地, 根据JavaDoc文档, hashCode() 方法在子类中没有被覆盖, 因而也忽略了纳秒数据.
java.sql.Timestamp的JavaDoc指出&inheritance relationship (...) 实际表示实现的继承, 而不是类型继承(这违反了继承的初衷). 但即使这句话是错误的, 既然Java没有私有继承的概念(也即继承实现). 所有java.sql.*包中的类应该被设计为封装一个java.util.Date对象, 而不是继承它, 仅暴露需要的方法 — 最起码, 方法比如hashCode() 应该被适当的覆盖.
最后一个评论是关于数据库引擎的时区的处理. 在java.sql.*包中的类不允许显式的设置时区. 数据库服务器(或驱动) 可自由的依据服务器server的当地时区解释这些信息, 且其可能被影响而变化(比如, 因为夏令时).
通过前面的讨论, 很清楚, Java的日期处理相关类并非很复杂, 但是没有被很好设计. 封装被疏漏, APIs结构复杂且没有被很好的组织, 且非常见的思路经常被无缘由的使用. 实现更有其它的莫名奇妙(提议看看Calendar.getInstance(Locale)对于所有可用locale实际返回对象的类型!) 另一方面, the classes manage to treat all of the difficulties inherent in internationalized date handling and, in any case, are here to stay. 希望这篇文章对帮助你搞清它们的用法有所帮助.
Call Me By My True Names
As a last example of the wonderful consistency and orthogonality of Java's APIs, I would like to list three (maybe there are more!) different methods to obtain the number of milliseconds since the start of the Unix epoch:
long java.util.Date.getTime()
long java.util.Calendar.getTimeInMillis() (New with JDK 1.4.1. Note that java.util.Calendar.getTime() returns a Date object!)
long java.lang.System.currentTimeMillis()
作者非常感谢Wilhelm Fitzpatrick (西雅图) 细心的阅读原稿和有价值的意见.
References
International Calendars in Java at IBM : A detailed white paper by one of the original authors on the genesis and intended usage of Java's date-handling classes. Highly recommended.
IBM alphaWorks: International Calendars: Additional subclasses of Calendar for Buddhist, Hebrew, Muslim, and Japanese calendars used to be available at IBM's alphaWorks. Unfortunately, they seem to be temporarily unavailable.
Reingold on Calendars: Web site of Edward M. Reingold, author of Calendrical Calculations, the standard reference on calendars.
About the Calendars: A brief overview of some of the more common international calendars.
Thread on JavaLobby: A brief, but interesting, thread on JavaLobby. Apparently, some people considered the APIs of Java's date classes to be so bad that they filed an official bug-report to have them changed. Unfortunately, the request has been rejected.
Philipp K. Janert, Ph.D. is a Software Project Consultant, server programmer, and architect.Java专业的学生出路在哪里?该怎么处理_pb在行业应用开发中渐行渐远解决思路_为什么不使用to_date()?解决思路__脚本百事通
稍等,加载中……
^_^请注意,有可能下面的2篇文章才是您想要的内容:
Java专业的学生出路在哪里?该怎么处理
pb在行业应用开发中渐行渐远解决思路
为什么不使用to_date()?解决思路
Java专业的学生出路在哪里?该怎么处理
Java专业的学生出路在哪里?如题、大二了、专业就是这个Java、这个课就学了一个学期、学校安排的学好多课程、比如数据库、数据结构、jsp等、每门课都是只学一个学期、到底这个专业将来往哪方面发展啊?工作做什么?就业前景如何?学校这样就学一个学期、还学那么多、虽然掌握多门课程有益、但以前学的都忘了……丫的出路在哪里……如果说我要从事和Java有关的行业、那要怎样安排一个学习计划呢?要学习怎样的技术去为将来找一个差不多的工作做准备呢?这里应该有很多从事类似工作的人,希望有人能回答一下~谢啦~------解决方案--------------------课程该完成的都得完成啊。多学点没坏处。再说,如果你要工作,不会数据库、数据结构是不行的。java目前就业比较广的有j2ee、android。
------解决方案--------------------楼上说我也赞同,我目前在上海NIIT培训JAVA,刚开始进去时老师就和我说了,数据库一定要有点基础的。就目前JAVA这个技能的发展前景还是很高的,我在智联招聘、前程无忧等大型的招聘网已经查过了,工作岗位很紧俏。所以楼主为了以后, 您一定要坚持。。。
------解决方案--------------------
主要是一个学期学一门技术、到下学期就全忘了……感觉掌握的并不是很多、搞不清楚到底是在学什么……
------解决方案--------------------一般来说,学会了java就可以维护世界和平
------解决方案--------------------多学点不会有什么坏处的。能学就尽量学,将来如果要进入IT行业,就得好好学。
------解决方案--------------------有人说计算机专业牛逼的人都不是老师教出来的,牛逼的人都是自己学出来的。。
------解决方案--------------------ls正解。jsp,数据库,数据结构,这些都是基础阿,学校的课还是有用处的。但是,仅仅掌握学校上课的那些是不够的,自己要在课余再好好深入的研究下。
------解决方案--------------------
引用:课程该完成的都得完成啊。多学点没坏处。再说,如果你要工作,不会数据库、数据结构是不行的。java目前就业比较广的有j2ee、android。主要是一个学期学一门技术、到下学期就全忘了……感觉掌握的并不是很多、搞不清楚到底是在学什么……
------解决方案--------------------
一般来说,学会了java就可以维护世界和平
------解决方案--------------------这些都要学的说。
------解决方案--------------------数据库必须用的,html必须会的,数据结构应该懂的,然后就看你想学java还是c#了。如果学java,jsp也是要会的,如果学c#,.net也是要会的。你学的这些,不都是要用得到的吗?
------解决方案--------------------楼主建议你去学习完后大三就去实习,必须学以致用,工资少没关系,主要是要有一个teamwork的经验,时间不要浪费在刀塔上面,这就是我的建议,一个大四java学生。
------解决方案--------------------这是啥大学啊?只听说过计算机专业,没听过JAVA专业的!一门语言也能叫专业吗?
------解决方案--------------------你是那个学校的啊?怎么跟我们学校的很像啊???
pb在行业应用开发中渐行渐远解决思路
pb在行业应用开发中渐行渐远从97年开始,我接触了pb,并迅速成为其忠实的追随者。在pb大行其道的年代里,我也陶醉其中,不亦乐乎。但形势在悄悄地变化,应用系统从典型的2层C/S应用向3层架构、B/S架构转变,pb在这个过程中一直没有明确的态度,一会儿偏向Java阵营,一会给.NET写datawindow插件,技术路线摇摆不定,始终没拿出自己的解决方案。就算我们有耐心等,客户也不会等。面对越来越多的B/S应用系统建立起来,客户坐不住了,纷纷要求把现有的系统进行B/S升级改造,新上的项目,必须要求B/S架构。
好多做pb的程序员,都有一个共同点,就是对pb之外的技术不怎么关注了,一切都想在pb这个平台上找解决方案。作为一个有十几年行业应用系统开发经验的程序员,技术实现早已不是我所关注的重点,我的精力大部分用在跟用户泡业务、搞数据库设计和系统架构设计上。多年来,pb一直是将我的设计思想转化为实际系统最方便的工具,也是我的不二之选。所以,面对客户强烈的B/S呼声,我们寝食难安。
不是我们不愿意学习B/S开发相关技术,也不是我们顽固不化,死守pb这块阵地,而是我们觉得行业应用软件的精髓在业务而不在技术形式,如果能够有一种开发工具,开发B/S架构的应用像pb开发C/S程序那样方便快捷,我们也会毫不犹豫的采用。但现在流行的B/S开发工具对web数据的处理都不理想,远不如pb的datawindow那么方便,前台后台都需要写大量代码,而且随着用户需求变化,其后期的维护工作量很大,特别是项目换人之后,接手人家留下的烂摊子那简直是一场恶梦。
看着pb在行业应用开发中渐行渐远,我无限感叹……------解决方案--------------------古老当时兴,说不准三五年后流行C/S
------解决方案--------------------
古老当时兴,说不准三五年后流行C/S
------解决方案--------------------同感,有点无奈,还是学点其他的语言吧------解决方案--------------------有个工具可以将pb的程序转换为B/S应用,Appeon,以前叫“正阳”,现在叫“爱普阳”,可以转换大部分代码。
------解决方案--------------------现在的bs也有很多很多插件可选择的,代码量不是很大,学习一下就可以上手。不要担心。
------解决方案--------------------现在流行的SSH开发模式,应付较小的应用或者需求相对确定的项目,也还行。前台可以用ExtJS来展现。经过几个项目的积累,也能提炼出一套自己的基础组件来。虽然比不上pb的datawindow那么方便,但只要项目需求明确,不经常换人,也还行。
------解决方案--------------------回15楼“只要项目需求明确,不经常换人,也还行”废话,需求明确的话,还说个鬼。要是项目需求不明确呢?项目经常换人呢?
------解决方案--------------------现在很多行业项目,一上来,数据库、webserver、java架构,业主全给你明确了,要求只能在这个架构下做开发。钱只给那么多,项目经理看着办。找十来个程序员写一大堆程序,解决一个小问题,还自鸣得意,评个科技进步奖。还是国外的厂家会忽悠啊,直接忽悠客户,搞的开发人员人不人鬼不鬼的。杯具啊杯具!
------解决方案--------------------写得好。
------解决方案--------------------回 楼主哥们儿人不错嘛
------解决方案--------------------搞了段时间flex,说是提倡富客户端,现在又回头来用PB,杯具啊
------解决方案--------------------呵呵,看来大家都对开发bs的程序有兴趣。
------解决方案--------------------
引用:古老当时兴,说不准三五年后流行C/S一、会流行,但不是以前理解方式,PB8一直很看好PB的多层架构,特别喜欢,开发效率高,系统又稳定;二、同意楼主的说法,如果只活在PB的世界里,你只能天天看天井口,如果多学几门语言,可以开拓你的视野,身边的几个牛人都是几门语言都熟悉,但只精通一门的,不同的语言可以让你从不同的角度去理解、认识计算机;三、多专注业务才是正道~~
------解决方案--------------------
引用:古老当时兴,说不准三五年后流行C/S一、会流行,但不是以前理解方式,PB8一直很看好PB的多层架构,特别喜欢,开发效率高,系统又稳定;二、同意楼主的说法,如果只活在PB的世界里,你只能天天看天井口,如果多学几门语言,可以开拓你的视野,身边的几个牛人都是几门语言都熟悉,但只精通一门的,不同的语言可以让你从不同的角度去理解、认识计算机;三、多专注业务才是正道~~
------解决方案--------------------
现在很多行业项目,一上来,数据库、webserver、java架构,业主全给你明确了,要求只能在这个架构下做开发。钱只给那么多,项目经理看着办。找十来个程序员写一大堆程序,解决一个小问题,还自鸣得意,评个科技进步奖。还是国外的厂家会忽悠啊,直接忽悠客户,搞的开发人员人不人鬼不鬼的。杯具啊杯具!
------解决方案--------------------的确如此,支持!!!
------解决方案--------------------
现在很多行业项目,一上来,数据库、webserver、java架构,业主全给你明确了,要求只能在这个架构下做开发。
钱只给那么多,项目经理看着办。找十来个程序员写一大堆程序,解决一个小问题,还自鸣得意,评个科技进步奖。还是国外的厂家会忽悠啊,直接忽悠客户,搞的开发人员人不人鬼不鬼的。杯具啊杯具!------解决方案--------------------powerbuilder也没有像yangjunsong说的那么悲观,对于传统软件分发和升级比较麻烦的问题,sybase在pb11办法中已经提供了智能客户端的解决方案。其实从pb12开始,pb已经和以前的版本已经是一个分水岭,在PB12中,不仅可以很好开发传统的c/s结构的程序,还可以开发WPF的程序等等,后面再将WPF程序转化到silverlight应用,那么PB开发b/s结构的程序,包括在界面等方面的问题都会迎刃而解,就像微软自己的web office一样。silverlight是跨平台的,那么用PB开发跨平台的的应用也非常有可能的,因为PB能直接编译成.NET程序,所以以后PB也可以实现云计算平台的程序。其实sybase一直在朝这方面努力,只是现在要做的东西太多了,还要等候很长的时间。其实以我个人对POWERBUILDER的观察,现在PB可以直接在PB开发环境下直接嵌入.net语言片段(条件编译)#if defined PBWINFORM Then
// #如果有一天,sybase再在开发环境中嵌入java语言片段,也不是没有可能(仅仅是猜测)。说这么多,希望大家对PB有信心点。
为什么不使用to_date()?解决思路
为什么不使用to_date()?公司的开发规范手册上面写着:SQL 语句规范:不要在SQL语句里面使用to_date函数,应该通过传入date/time类型参数的方法来实现!也就是说在SQL语句里面看到to_date函数是不符合要求的。这样的话,如果查询两个时间段之间的数据,例如下面这句,应该怎么写查询语句between to_date( ' 20:20:20 ','yyyy-MM-DD hh-mm-ss') and to_date( ' 22:22:22','yyyy-MM-DD hh-mm-ss')还有我不知道为什么不要用to_date(),是效率方面的原因吗?------解决方案--------------------我目前使用的数据库,在sql语句的时候,如果碰到需要日期的地方一定得加to_date()进行转换,不知道为什么,不加的话语句就会出现错误。
------解决方案--------------------像hibernate等都支持直接日期类型的映射,直接java的日期类型就可以使用,确实不建议使用字符串进行处理,这种代码在不同的国家可以就无法使用了,而直接使用date类型就没有这种问题
------解决方案--------------------to_date应该没什么影响吧?有些东西不加to_date似乎无法处理。
------解决方案--------------------sql的where条件中的值使用传参数的方式是一个好习惯,这样的sql效率高。
------解决方案--------------------你误解了公司的开发规范了。公司规范的意思是说在高层语言如java、c#等中调用sql的时候不能在sql中出现to_date,而是通过直接传入date类型来进行查询。类似
date a,b= ....PrepareStatment s = 'select * from test where mydatecolumn between ? and ?'s.set(1) =s.set(2) =而不是使用s = 'select * from test where mydatecolumn between to_date(
' 20:20:20
', 'yyyy-MM-DD hh-mm-ss ') and to_date(
' 22:22:22 ', 'yyyy-MM-DD hh-mm-ss ')'因为这样会出现数据的不一致,比如出现不符合要求的日期:而抛出异常。按照公司规范就不会有问题了。ps:在直接使用sql访问数据库的时候肯定要用to_date的。
------解决方案--------------------楼上的理解或许是正确的
如果您喜欢IT行业或者对IT行业感兴趣,想开拓技术视野,欢迎加入本站官方QQ群:,在群里认识新朋友和交流技术^_^
本站联系邮箱:

我要回帖

更多关于 不明确 英文 的文章

 

随机推荐